JPH07325744A - Data base form converting method and its device - Google Patents

Abstract

PURPOSE:To convert a data base into another form without losing its original form and while carrying on the accesses to the data base. CONSTITUTION:When a conversion processing instruction is received, the contents of an original data base 14 are immediately frozen. A data base conversion processing part 13 converts the contents of the base 14 into a desired data form and successively stores them in a copy data base 15. Meanwhile the base 14 is not rewritten even when an updating request is given to the base 14, and the updating record is recorded into a log file 20 for execution of the updating processing. Then the contents of both bases 14 and 15 are updated based on the contents of the file 20 after the contents of the original base 14 are completely converted.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database system, for example, when the data format such as each field length of the database is changed in accordance with the change of the usage pattern or when the database is migrated to a different model having different data handling The present invention relates to a database format conversion method and apparatus for converting a database into another format.

[0002]

2. Description of the Related Art In a database built on an information processing system, when it becomes necessary to change the data format due to a version upgrade of a system program, or when trying to migrate to a different model with a different code system, etc. Conventionally, a new database was created by temporarily stopping the system and executing a program for database migration.

As an example in which this is improved, Japanese Patent Laid-Open No. 5-23
There is a "migration method in an online processing system" disclosed in Japanese Patent No. 3408.

FIG. 10 to FIG. 13 are explanatory views showing this conventional database format conversion method. This method is carried out through the four phases shown during online processing.
It is to migrate the database.

This method employs a system in which the disk has a double structure. As a result, it is possible to carry out the database format conversion work on another system while continuing the online service on one system of the disk, and to restart the online service from the new system when the work is completed.

Next, the flow of processing in this conventional method will be described. First, Phase 1 (Fig. 10) shows the file status during regular online service.
As shown in the figure, the data file has a dual structure. When changing data, both files are accessed and updated at the same time. That is,
In phase 1, the data files of the two systems always have the same contents.

Phase 2 (FIG. 11) shows the first step of the database format conversion work. In this phase, one of the two systems of disks is disconnected from the online service, and the disk on this separated disk is separated. Then, the migration to the new file, that is, the system program included in the program file is changed and the database format is converted. And normal online services continue with the other disk.

After the completion of the work of shifting to the new file in phase 2, in phase 3 (FIG. 12), the system is temporarily stopped, the disk is switched, and the online service is restarted by the new program file and the new data file. To do.

When the online service by the new program file and the new data file is stabilized, the old program file and the old data file are updated in phase 4 (FIG. 13) in order to return to the normal processing state in the dual configuration. Move to file.

As described above, according to this conventional method, it is possible to suppress the service stop time accompanying the shift to the new system without stopping the system.

In addition to such a method, as a method taken for dynamically converting these databases without stopping the system, Japanese Patent Publication No. 4-7734.
There is a "dynamic change method of data items in record type data" disclosed in Japanese Patent Laid-Open No. 0 (JP-A-60-10362).

Conventionally, a record in a file such as a database has a fixed record length, and once created, the record making up the file cannot be changed.
This method is an improvement over making the record variable length at most and adding the data item to the end.

In this system, for each data item, an item cell holding the attribute of the data item in advance, a physical array order pointer for indicating the physical array order of the data item on the record, and valid data. A display order pointer or the like indicating the logical display order of items is held in the record definition storage unit and used when changing data items. As a result, even if a data item is added, deleted, or the attribute of the data item is changed, the information in the record definition storage section is used without changing the record existing in the previously created file. It is treated dynamically as if the record definition of the data item was changed by re-interpreting it when accessed. Therefore, according to this method, it is possible to deal with a data definition change without changing the record definition all together.

FIG. 14 is a block diagram showing this conventional database dynamic modification method. In FIG. 14, the external schema 35 holds the current record format, and the internal schema 36 includes the current record format. The physical data item structure is retained. In this conventional system, a data read request from the user 30 to the database is transmitted to the logical database access system 33 via the relation operation system 31 and the record access system 32. The logical database access system 33 refers to the external schema 35 and translates this request into a set of instructions to the physical database access system 34. Physical database
The access system 34 reads the corresponding record from the database 37 by comparing the internal schema 36 and the database 37, and passes it to the logical database access system 33. The logical database access system 33 converts the received record into the representation format of the external schema 35 according to the correspondence between the external schema 35 and the internal schema 36, and then the record access system 32 and the relation operation system 3
Return to user 30 via 1. In addition, the database 37
, The command received by the logical database access system 33 as a request for a record in the form of the external schema 35 is reflected by the internal schema 36 on the actual database 37.

[0015]

DISCLOSURE OF THE INVENTION Problems to be Solved by the Invention
The conventional migration method disclosed in Japanese Patent Laid-Open No. 8 is a system in which, in a system having a dual disk configuration, the migration work is carried out on another system while the online service is continued on one system. It is a major premise that the system has a dual structure, and a system using a normal single disk cannot take this method even if there is enough disk capacity. Further, since it is necessary to hold two data and programs having the same content during a regular online service, there is a problem that a large storage capacity is required.

On the other hand, in the conventional data item dynamic change method disclosed in Japanese Patent Publication No. 4-77340, in order to protect the previously created data item as it is, the physical arrangement of records and the logical arrangement are used. The arrangement and the arrangement had to be stored in advance as a record definition storage unit, and the dynamic change could not be made during use. Also, with this method, as the number of changed records increases, the processing overhead eventually increases, so in order to improve performance, it is necessary to convert all records to the latest format at once. You will need it.

Further, in recent years, the necessity of changing a data item is not limited to a change in a record array due to the addition or deletion of a data item or a change in a data item due to a change in an attribute of a data item. There is also a demand to completely change the format of data items with the migration of databases between models, and in such a case, it is necessary to change a large number of data items. For example, in the case of different models, the character code may be changed, and the data item may be changed by changing the field length of the data item.In such a case, this conventional data item dynamic change method is not applicable. It is difficult, and eventually there is a problem that the method of batch conversion will have to be adopted.

The present invention has been made in order to solve the above problems, and collectively converts data items of a database without losing existing databases and files, and It is an object of the present invention to provide a database format conversion method capable of dynamically converting the above without stopping normal processing such as online processing of the database.

[0019]

In order to achieve the above object, the invention according to claim 1 is a database format conversion method for converting a first database into a second database having a different data format. A data format conversion step of prohibiting updates to the first database and converting the fixed first content database to a different data format to create a second database; When there is an update request to the first database, an update log file creation step of recording the update content in an update log file, and after the data format conversion step is completed, based on the update log file, Data for reflecting the update contents generated during the data format conversion process in the first database and the second database And a over scan update process, while preserving the first database with the original data format, characterized by creating a second database having a different data format.

According to a second aspect of the present invention, in the database format conversion method according to the first aspect, communication is performed with another computer system connected to the network,
The second database is created on the other computer system.

The invention according to claim 3 is the database format conversion method according to claim 1, characterized in that during the data format conversion step, concealment processing is performed on the second database.

The invention according to claim 4 is the database format conversion method according to claim 1, wherein during the data format conversion step, each field of the first database is changed from a program that accesses the first database. Field attribute information is extracted, and based on the field attribute information, it is determined whether the field length should be expanded or reduced for each field when converting the data format, and the field length is expanded or reduced. If it is necessary, the field length after data format conversion is obtained based on the field attribute information.

According to a fifth aspect of the present invention, in the database format conversion method according to the first aspect, an operator inputs the field length of each field of the second database from the outside during the data format conversion step. It is characterized by having a process.

The invention according to claim 6 is the database format conversion method according to claim 5, wherein the operator accesses the first database when the field length of each field of the second database is designated. It is characterized in that the field attribute information of each field of the first database is extracted from the program and notified to the operator.

The invention according to claim 7 is that in the database format conversion method according to claim 1, before starting a series of database format conversion processing, a step of setting a processor for performing the processing is provided. Characterize.

The invention according to claim 8 is that in the database format conversion method according to claim 1, before starting a series of database format conversion processing, a step of designating an execution priority of the processing is provided. Characterize.

According to a ninth aspect of the present invention, the first database constructed on the first computer, the first database constructed on the second computer connected via a network, and having a different data format are constructed. A database format conversion method for converting to a second database, which prohibits update to the first database and transfers the fixed contents of the first database to the second computer via a network. A step, a data format conversion step of converting the transferred contents of the first database into a different data format on the second computer to create a second database, and the data format conversion step during the data format conversion step. When an update request is made to the first database, an update log file is created to record the update content in the update log file on the first computer. And a database update for reflecting the update contents generated during the data format conversion step to the first database and the second database based on the update log file after the step and the data format conversion step are completed. And storing a first database having an original data format, and creating a second database having a different data format.

Further, the invention according to claim 10 is a database format conversion device for converting a first database into a second database having a different data format, wherein updating of the first database is prohibited, Data format conversion means for converting the first database having a fixed content into a different data format to create a second database, and an update request for the first database during processing of the data format conversion means If there is, the update log file creating means for recording the update content in the update log file, and after the processing of the data format converting means is completed, based on the update log file, the first database and the second database Database updating means for reflecting the update contents generated during the processing of the data format converting means in the database The a, while preserving the first database with the original data format, characterized by creating a second database having a different data format.

[0029]

In the database conversion method according to the present invention, first, in the data format conversion step, the first
The update of the database is prohibited to prevent the recorded contents from being changed, and the data format of the data of the first database in this state is converted into a second database having a desired data format. If there is an update request for the first database during this data format conversion process, the update content is recorded in the update log file without directly updating the first database. If there is an access request to the first database during the data format conversion process, the latest data can be obtained by referring to the first database and the update log file. Then, when the data format conversion step is completed, the first database and the newly created second
The database of is updated based on the update contents recorded in the update log file. As a result, it is possible to perform conversion of the data format while minimizing access restrictions to the first database, and it is also possible to save the first database having the original data format.

According to the second aspect of the invention, the disk capacity of the computer is created by creating the second database while performing network communication on a computer system different from the computer system having the first database. The database format conversion process can be performed even when there is a shortage.

According to the third aspect of the invention, the second database being created in the data format conversion step is hidden from the user and cannot be accessed. This prevents the conversion process and the incomplete database from being rewritten.

Further, in the invention according to claim 4, in the data format conversion step, attribute information of each field of the first database is extracted from the program for accessing the first database, and the data is converted based on the attribute information. It is determined whether the field length of each field should be changed during format conversion. When it is determined that the field length should be changed, the field length after format conversion is calculated based on the attribute information. Thereby, the field length of each field of the second database can be automatically obtained.

According to the fifth aspect of the invention, the field length of each field of the second database can be input from the outside in the data format conversion step. This makes it possible to more finely specify the field length when converting the data format.

According to the invention described in claim 6,
When the field length is input in the method according to the described invention, the operator is informed of the attribute information of each field of the first database. The operator can refer to this when determining the field length of the second database.

Further, according to the invention described in claim 7, since the processor for performing the format conversion process is designated before performing the format conversion process for the series of databases, the processor for performing the normal data process for the first database is secured. can do.

According to the present invention, the execution priority of the conversion process can be set before the format conversion process of the series of databases. Therefore,
By setting the conversion process priority low,
The conversion process can be performed without disturbing the normal data processing work for the first database.

In the invention according to claim 9, when performing the database format conversion process, first, in the data transfer step, the update is prohibited and fixed for the first database constructed on the first computer. The contents of the first database are transferred to the second computer. Next, in the data format conversion process, the second computer transfers the first transferred data.
Convert the contents of the database to different data formats,
Create a second database. If there is an update request for the first database during the database format conversion step, the update content is recorded in the update log file on the first computer in the update log file creation step. Then, when the data format conversion is completely completed, the database update step reflects the update content recorded in the update log file in the first and second databases.

Further, in the database conversion apparatus according to the tenth aspect of the invention, the data format conversion means is
The update of the first database is prohibited so that the recorded contents are not changed, and the data format of the data of the first database in this state is converted to create the second database having a desired data format. If an update request is made to the first database during the processing of the data format conversion means, the update log file creation means updates the update log file without directly updating the first database. Record the contents. Therefore, if there is an access request to the first database during the processing of the data format conversion means, the latest data can be obtained by referring to the first database and the update log file. Then, when the processing of the data format converting means is completed, the database updating means updates the first database and the newly generated second database based on the update contents recorded in the update log file.
As a result, it is possible to perform conversion of the data format while minimizing access restrictions to the first database, and it is also possible to save the first database having the original data format.

[0039]

Embodiments of the present invention will be described below with reference to the drawings.

First Embodiment FIG. 1 is a block diagram showing a first embodiment of the present invention.

In FIG. 1, a user 10 indicates a command input by the user, an application program of the user who accesses this system, and the like, and includes information about a database attached to these. The system administrator 11 represents the operation of an operator who manages the system for the entire system. In the present embodiment, the database processing system 16 has a database access processing unit 12 and a database conversion processing unit 13, and performs normal database access processing and database format conversion processing. Details will be described below with reference to the flowchart of FIG.

Database 14 used until then
Consider the case of converting to a new format. Normal,
Such processing is performed as an operation of the system administrator 11 of the system. The system administrator 11
The program of this system is started for this conversion.

The started program operates according to the flowchart of FIG. First, the database conversion processing unit 13 inputs the original database 14 and converts the database into a desired new database format (step 100). The converted output is generated as a file of the copy database 15 as an output file after conversion (step 101).

During this period, it is possible to stop the processing relating to the access from the general user 10 to the original database 14 and perform such conversion, but this causes a hindrance to normal business, so In this embodiment, processing such as access from the user 10 through the database access processing unit 12 is continuously performed.

Since the format conversion of the database takes a time corresponding to the size thereof, when the conversion is carried out while continuing the online business, the conversion work is in progress (step 100).
It is necessary to assume that an update request is issued to the database during the work (1 and 101). In this embodiment,
At the start of the conversion work, the database 14 is separated from the service so that the data content is not changed, and the recorded contents of the database 14 at the start of the conversion work are converted into a desired format and recorded in the copy database 15. When a request for updating the database being converted is received, the original database 14 is not actually updated, but the updated contents are recorded in the log file 20 (step 102). . As for the recording, a method of recording the record before update and the record after update is sufficient as in the normal method used when journaling a file.

When an update request for the original database 14 arrives, the logical state of the database before update can be obtained by referring to the original database 14 itself and the contents of the log file 20. So
This will be updated.

In the flowchart of FIG. 2, step 1
Although the processing of 02 is described as the processing after step 101 for the sake of convenience, in reality, this step 102 is
This is performed during the processing of step 100 and step 101. As a result, since the original database is saved as it is, the conversion target is not updated in the process of the database format conversion step 100, and there is no effect.

In the present embodiment, when the processing of the database format conversion in step 100 is completed, not only the original database 14 but also the copy database 15 created based on the original database 14 is converted. It reflects the old data contents before the start. When the database conversion process is completed, it is necessary to reflect the update that occurred during the conversion process in the original database 14 and the copy database 15. Therefore, the original database 14 and the copy database 15 are updated based on the contents of the log file 20 (step 103). Here, when the log file 20 is described in the data format of the original database, the database format conversion process is also performed at the same time when the copy database 15 is updated.

When the database format conversion is completely completed in this way, the business program for updating the database from the user 10 (the business program is omitted as being represented by the user 10) corresponds to the converted database. A new business program (when the business program has been updated) is switched to, and normal business is resumed using the copy database 15. Of course, the database format may be converted even when the business program is not updated, and in this case, the normal business is restarted by the business program.

If this switching is performed while online, it is possible that the original database 14 and the copy database 15 may have inconsistency in data at that moment. In this case, it is conceivable to temporarily stop the online processing, perform the recovery work, and then restart the processing.However, in this system, the update log of the database during online work is not only converted during the conversion work but also converted. The system is configured to continuously record even after the work is completed, and by keeping this update log even after the conversion is completed, the online system is available until the time when the online processing must be stopped (for example, the end time of the online business of one day). Can be operated as it is, and after the stop time, the work of recovering the consistency between the original database 14 and the copy database 15 can be performed according to the update log. In this configuration, the system is operated by the copy database after the transfer from the time when the online business is restarted.

In the present embodiment, for convenience of explanation, the original database 14 and the copy database 15 are shown as if they were different disk devices, but the present invention is not limited to this, and a sufficient disk capacity is provided. If it exists, it is possible to create it as two logically different databases in the same disk device.

Second Embodiment FIG. 3 is a block diagram showing a database conversion method in the second embodiment of the present invention. The present embodiment shows an example of database conversion using a network system, in which the output converted from the original database 14 is transmitted to another host computer connected to the network and connected to this other host computer. The copy database 15 is created on the file device. Therefore, in this embodiment, the database processing system 16 includes the communication control unit 1
7, the conversion output of the database 14 and the log file 20 by the database conversion processing unit 13 is transmitted to the other system host 19 via the network 18.
The other components are the same as those in the first embodiment.

FIG. 4 is a flow chart showing the flow of processing in this embodiment. The basic processing flow is
This is almost the same as the embodiment, but after the format conversion of the database (step 100), the conversion data is transferred by communicating with the other system host 19 via the network 18 (step 1).
10) Then, the point that the other system host 19 is made to process the generation of the copy database 15 is different from the case of the first embodiment. The communication function with the host of another system can be realized by using the network function supported by many operating systems and the communication function such as RPC (remote procedure call). In this embodiment, the work of transferring the conversion data to the host 19 of the other system by communication (step 110) includes a database format conversion process (step 100) and a copy database creation process (step 101). The period is always done.

In this embodiment, the database format conversion is performed in the database processing system 16 and the converted data is transmitted to the other system host 19.
Data whose format has not been converted is transmitted from the database processing system 16 to the other system host 19, and the other system host 19
It is also possible to adopt a configuration in which the format conversion of the database is performed. Even when the load on the host computer having the database system 16 is heavy, the data format can be smoothly converted by such a configuration.

Third Embodiment FIG. 5 is a flow chart showing the processing flow of the database conversion method of the third embodiment of the present invention. The basic processing flow is almost the same as in the first embodiment, but in this embodiment, a copy database is created (step 10).
Before step 1), a step 120 for concealing the copy database is added. That is, when a copy database is generated using the output of the database format conversion step 100, the generated copy database file is set so that it cannot be accessed by an ordinary user. That is, when the database conversion process is performed, if the intermediate file (copy database) being converted is visible to the user, the user may mistakenly access the file and cause a failure. In order to prevent this, conceal the copy database.

The copy database concealment process 120 itself can use a method of controlling so-called file access permission. Taking the C language interface as an example, it can be realized by specifying the permission for prohibiting the access to the copy database in the interface such as chmod (copy database name, access permission).

In this case, as the access permission, it is conceivable to prohibit the reading in order to prevent erroneous reading due to reading the file, as well as to specify the writing prohibition.

The concealment process can be realized by using a method of creating a hidden file in addition to the method of controlling the access permission.

Fourth Embodiment FIG. 6 is a flow chart showing a fourth embodiment of the present invention. The basic processing flow is almost the same as that of the first embodiment. However, in this embodiment, after the database format conversion (step 100), each field of the database is expanded / extended in the data format conversion. A step 130 of determining whether or not to be reduced is provided, and if it is determined to be extended or reduced, a step 13 of calculating a new size of the field to be extended or reduced is provided.
By 1, the size of the new field according to the desired data format is obtained.

An application program that accesses such a database holds attribute information of each field of the database. By extracting it, if the field handles only numeric data, it can be determined that the field will not be expanded or reduced even if the code system is changed. However, if the field is a character (character), the field length may change when the code system changes due to the conversion of the data format. In this way, the possibility of changing the field length can be determined from the attribute information of each field of the database extracted from the application itself.

For example, it is assumed that the original database only supports English and all character codes are represented by 1 byte. Assuming that the purpose of database migration is to support Japanese, the Kanji code for Japanese is usually 2 bytes, and in some cases it is 3 bytes. If you want to be able to correspond to 80 Japanese characters, you can simply calculate that a field of 160 bytes or more is required. Of course, even in such a case, each field of the database is not necessarily required to correspond to Japanese uniformly in the data format conversion, and there may be a field corresponding to English. In this case, regarding that field, There is no need to extend the field length. On the contrary, when changing the software supporting Japanese to only English, the field length may be reduced. In addition, there is a case where a certain field is uniformly reduced due to the demand for reducing the disk capacity.

Therefore, in step 131, based on such a request, the length of each field is automatically calculated according to the attribute information of the database before conversion and the data format after conversion.

The extension calculated by step 131,
Alternatively, the new size of the field to be reduced is passed to the step 101 of creating a copy database, and the copy database 15 is created at the time of file creation with the record length according to the calculated size of each field.

As described above, in this embodiment, when converting the format of the database, it is determined whether or not the field length needs to be expanded or contracted in accordance with the conversion of the data format. , The field length of each field can be automatically calculated according to the new data format. Therefore, the present embodiment can be applied to the case of porting a database to a different model.

Fifth Embodiment FIG. 7 is a flowchart showing the fifth embodiment of the present invention. The basic processing flow of this embodiment is almost the same as that of the first embodiment. However, in this embodiment, the field length of each field in the copy database is set by the system administrator 11 etc., especially at the time of database format conversion processing. As an operator's operation, a step 140 for manually inputting and reading this input is provided.

Various data can be considered in each field of the database. For example, assume that the database is a database that manages sales of products. In this case, if there is a field showing the price of the product,
It is a field that stores only numbers, and in this case, it is unlikely that the field length will be changed by code conversion. However, even in such a case, it is conceivable that the size of the amount field will be expanded in preparation for an increase in the transaction volume of the product.

In the case of a field in which characters are used, such as a product name field, the field length can also be determined by determining whether Japanese is used or English only. .

In such a case, not only the simple field attribute but also the user's judgment is required. In the present embodiment, each field of the copy database can be manually input as an operation of the system administrator 11 so that the result of this human judgment can be input as information for database conversion. .

For example, if there are 5 fields in the database to be changed, in step 140 for reading the field length of the data input from the outside, the system administrator 11 for each field of the database. Prompts for the field length. In this case, the input is urged and accepted five times corresponding to the five fields. Thereby, the field length of the database after the data format conversion can be adjusted to an appropriate length.

At this time, the attribute information of the database before format conversion is read from the application accessing the database, and the read attribute information is read by the system administrator 1.
With the configuration in which it is displayed to the operator such as 1 or the like, the operator can determine and input an appropriate field length in the database after data conversion while referring to the current state of the field attributes.

Sixth Embodiment FIG. 8 is a flowchart showing the sixth embodiment of the present invention. The basic processing flow of this embodiment is almost the same as that of the first embodiment, but before performing the entire processing, it is determined whether the system has a multiprocessor configuration and the multiprocessor configuration In this case, a step (step 150) of explicitly assigning the database format conversion process to a specific processor is provided, which is different from the first embodiment.

This step 150 is a processor-bind when the interface of C language is taken as an example.
(Conversion process name, execution CPU number); and can be realized by specifying the number of the execution CPU of the process executing the conversion processing program.

The method using such an interface is a function provided in an operating system that supports some multiprocessors, but if it is performed based on an operating system that does not support such a function. This can be achieved by extending the operating system and adding functions. Therefore, when the start of the database format conversion process is instructed, the processor may be automatically designated by such an interface.

The database conversion in this embodiment is intended to save the existing database as it is and to perform the database conversion without stopping the online processing for the normal database.
It is not preferable that the conversion process consumes a large amount of CPU power and the response of a normal online process is deteriorated. Therefore, if the entire database conversion process is assigned to a specific processor and the normal online process is executed by the other processors, the response is hardly reduced from the viewpoint of a general user.

Seventh Embodiment FIG. 9 is a flowchart showing the seventh embodiment of the present invention. The basic processing flow is almost the same as that of the first embodiment. However, in this embodiment, in addition to the processing in the first embodiment, the conversion processing is executed before the entire conversion processing is performed. There is provided a step (step 160) of setting a low priority (priority order).

The process of step 160 can be realized by setting the execution priority of the data format conversion program itself to be low in an interface such as nice (execution priority); .

Such an interface is provided in many operating systems. However, even if such an interface is not provided, the operating system can be extended to easily add such a function. Therefore, when the start of the database format conversion process is instructed, the priority may be automatically set through such an interface.

As described above, the object of the present invention is to preserve the existing database as it is and to perform the database conversion without stopping the online processing for the ordinary database.

Since such database conversion consumes a considerable amount of CPU power, when the database conversion process is started, there is a possibility that the response such as a normal online process may deteriorate. Therefore, the entire database conversion process is set to a low priority in advance and executed, so that the CPU preferentially executes the normal online process, and causes the CPU to execute the database conversion process when the CPU has room. be able to. In this way, the response of the normal online processing is hardly deteriorated by the general user.

[0080]

As described above, according to the invention described in claim 1, when the format conversion of the database is performed, the data items of the database are collectively changed without losing the existing database and files. be able to. Further, during this conversion processing, by recording the information of the online processing of the database as log information, the first database before conversion and the second database created by the conversion are generated during the conversion processing. Since the contents of the changed data are reflected, the database conversion process can be dynamically performed in parallel with the online process without stopping the normal online process.

According to the second aspect of the present invention, when the second database is created in the conversion process, the file of the second database after the database conversion process is performed by communication via the network is stored in another computer. It can be provided on the upper disc. As a result, the conversion process can be performed even when the disk capacity on the local machine is insufficient.

According to the third aspect of the present invention, when the second database is generated in the conversion process, the second database is hidden from the user, so that the incomplete database is in the process of the conversion process. It is possible to prevent a failure due to user access. Furthermore, there is an effect that it is possible to prevent an illegal process from being performed on the database during the conversion process.

According to the invention described in claim 4, when the second database is generated in the conversion process, the step of determining the possibility of expanding or reducing the size of each field of the database, and the field of the database are determined. Since the step of calculating the size of the field when expanding or contracting is provided, there is an effect that the field length can be automatically changed when the second database is created. Therefore, according to the invention of this claim,
Enables migration of heterogeneous databases.

According to the fifth aspect of the invention, when the second database is created in the conversion process, the operator inputs it from the outside in order to determine the field length of the second database created. Since the data can be read as the field length, there is an effect that the change of the field length due to the conversion of the database can be made efficiently and finely set by reflecting the operator's request.

According to the invention of claim 6, when the operator designates the field length of each field of the second database, the attribute information of the first database before format conversion is displayed to the operator. By notifying, the operator can determine an appropriate field length with reference to the display.

According to the seventh aspect of the invention, the second database generation process in the database conversion process is assigned to a specific processor so that another processor can be used for normal online processing. Since it is possible to secure the above, there is an effect that it is possible to prevent the response of the normal online processing from being deteriorated.

Further, according to the invention described in claim 8, since the step of suppressing the execution priority of the program for performing the processing of the second database generation in the conversion processing is set to a low level, a normal online operation is performed during the conversion processing. It is possible to prevent the response such as processing from being deteriorated.

Further, according to the invention described in claim 9, since the main processing of the format conversion of the database can be performed by the second computer, when the load of the first computer having the first database system is large. However, you can convert the format of the database.

According to the tenth aspect of the invention, when the format conversion of the database is performed, the data items of the database can be collectively changed without losing the existing database and files, and the conversion process is being performed. It is possible to reflect the contents of the data change that has occurred in the first database and the second database, and to perform the database conversion processing dynamically in parallel with the online processing without stopping the normal online processing. It is possible to obtain a database format conversion device that can be performed.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of a database format conversion system according to the present invention.

FIG. 2 is a flowchart showing a first embodiment of the database format conversion method according to the present invention.

FIG. 3 is a block diagram showing a configuration when the database format conversion system according to the present invention is applied to a network system.

FIG. 4 is a flowchart showing a second embodiment of the database format conversion method according to the present invention.

FIG. 5 is a flowchart showing a third embodiment of the database format conversion method according to the present invention.

FIG. 6 is a flowchart showing a fourth embodiment of the database format conversion method according to the present invention.

FIG. 7 is a flowchart showing a fifth embodiment of the database format conversion method according to the present invention.

FIG. 8 is a flowchart showing a sixth embodiment of the database format conversion method according to the present invention.

FIG. 9 is a flow chart showing a seventh embodiment of the database format conversion method according to the present invention.

FIG. 10 is a diagram for explaining a conventional database migration method.

FIG. 11 is a diagram for explaining a conventional database migration method.

FIG. 12 is a diagram for explaining a conventional database migration method.

FIG. 13 is a diagram for explaining a conventional database migration method.

FIG. 14 is a block diagram showing a conventional data item dynamic change method.

[Explanation of symbols]

10 users, 11 system administrator, 12 database access processing unit, 13 database conversion processing unit,
14 databases, 15 copy databases, 16
Database processing system, 17 Communication control unit, 18
Network, 19 Other host computer, 20
Update log file.

Claims (10)

[Claims] 1. A database format conversion method for converting a first database to a second database having a different data format, wherein updating of the first database is prohibited, and the first content of the fixed content is prohibited. A data format conversion step of converting the database into a different data format to create a second database; and updating the update content when there is a request for updating the first database during the data format conversion step. An update log file creation step of recording the log file, and after the data format conversion step is completed, based on the update log file, the first database and the second database
A database updating step of reflecting the update contents generated during the data format converting step in the database of 1), and a first database having a different data format while storing the first database having the original data format. 2. A database format conversion method characterized by creating a database of 2. 2. The database format conversion method according to claim 1, wherein communication is performed with another computer system connected to a network, and the second database is created on the other computer system. Database format conversion method characterized by. 3. The database format conversion method according to claim 1, wherein in the data format conversion step, concealment processing is performed on the second database. 4. The database format conversion method according to claim 1, wherein in the data format conversion step, field attribute information of each field of the first database is extracted from a program that accesses the first database. , Based on the field attribute information, it is determined whether or not the field length should be expanded or reduced for each field during the data format conversion. A database format conversion method characterized in that a field length after data format conversion is obtained based on attribute information. 5. The database format conversion method according to claim 1, wherein in the data format conversion step, an operator inputs a field length of each field of the second database from outside. And database format conversion method. 6. The database conversion method according to claim 5, wherein, when an operator designates a field length of each field of the second database, the first database is accessed from a program that accesses the first database. A database format conversion method, characterized in that the field attribute information of each field is extracted and notified to the operator. 7. The database format conversion method according to claim 1, further comprising a step of designating a processor for performing a series of database format conversion processes before starting a series of the database format conversion processes. Method. 8. The database format conversion method according to claim 1, further comprising a step of setting an execution priority of the series of database format conversion processes before starting a series of the database format conversion processes. Method. 9. A database format for converting a first database constructed on a first computer into a second database constructed on a second computer connected via a network and having a different data format. A conversion method, which comprises a data transfer step of prohibiting updating of the first database and transferring the fixed contents of the first database to the second computer via a network. A data format conversion step of converting the contents of the first database into a different data format on the second computer to create a second database; and an update request to the first database during the data format conversion step. Update log file creation step of recording the update content in the update log file on the first computer, if there is, and the data format After the conversion process is completed, on the basis of the update log file, the first database and the second
A database updating step of reflecting the update contents generated during the data format converting step in the database of 1., storing a first database having an original data format, and having a different data format. 2. A database format conversion method characterized by creating a database of 2. 10. A database format conversion device for converting a first database into a second database having a different data format, wherein updating of the first database is prohibited, and the first content of the fixed contents is updated. Data format conversion means for converting the database to a different data format to create a second database, and update contents when there is an update request to the first database during processing of the data format conversion means An update log file creating means for recording in the update log file, and the data format for the first database and the second database based on the update log file after the processing of the data format converting means is completed. Database updating means for reflecting the update contents generated during the processing of the converting means, and the original data format While preserving the first database having a different database format conversion apparatus characterized by creating a second database having a data format.