JPH06180720A - Method for grasping updating history of relational data base - Google Patents

Abstract

PURPOSE:To easily and quickly grasp the history of updated contents. CONSTITUTION:A table name to be outputted and a key to be outputted are specified (step 105) for a file formated as a log analyzing file only for a table to be referred to out of a log file in which access information from all programs to a relational data base 2 is recorded, list edition is executed (steps 106, 107) based on the specified keys and an updated data name is outputted (step 108) together with the cotents of data.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for ascertaining the update history of a database, and more particularly to a method for ascertaining the update history of a relational database (DB2). is there.

[0002]

2. Description of the Related Art Relational database (RD)
B) is a database model developed by IBM Corporation of the United States, and is used in many office computing systems from general-purpose computers to workstations. DB2 (dBASE I
There is a feature I), that the user can set the item by himself and can easily index the item, and can design the database as if he / she became a programmer.

Consistency test of a program using DB2 (test for each program of the entire system)
At the stage of, it is required to chronologically determine which program is doing what (hereinafter referred to as update history grasp).

Conventionally, the update history is grasped by solid-printing the log data as shown in FIG. 7 based on the table format defined as shown in FIG. 6, and the person in charge analyzes it manually. . The table format is a four-digit number that specifies the start line, item name (up to 6 letters, here "YAKJNO" (contract number), "UN
"ITNO" (unit number) is described) and the length (the number of digits is specified by a four-digit number). On the other hand, as the log data, data before updating (uppercase English) and data after updating (lowercase English) are written together, and both data are continuously output in the input order.

Here, a conventional method of analyzing the data content of log data will be described by taking the item name "UNITNO" as an example. For the item name "UNITNO", the start line is "0
Since it is the fifth digit of "005", the data "E" of the fifth digit of the data string starting from "A" is the starting digit. Then, since the length designation is "0006", "EFGHIJ"
Is the content of the item name "UNITNO".

[0006]

However, in the above-mentioned prior art, when analyzing the data contents, the analysis work is performed while manually counting the number of digits while referring to the table format, which requires a great deal of time. Was required, and the work efficiency was extremely poor. Also, due to manual work,
Mistakes are easy to make.

Therefore, an object of the present invention is to provide a method for grasping the update history of a relational database that enables the history of update contents to be easily and quickly grasped.

[0008]

In order to achieve the above object, the present invention uses a log analysis file only for a table to be referred to in a log file in which access information from all programs to the relational database 2 is recorded. For the formatted file, the output target table name and the output target key are specified to perform list editing, and the updated data name is output together with the data content.

A means for automatically generating a program for editing the list for each table to be analyzed can be provided so that the table to be analyzed can be easily added.

[0010]

According to the above means, when the key and the output target table name are specified for the log data read from the log analysis file, the list edit process of the target table is linked to update the updated items. Data names and data contents are listed in pairs. Therefore, the update history can be grasped quickly and accurately, and the quality can be improved in the consistent flow test.

Further, a program for editing the list for each table to be analyzed is automatically generated based on the processing pattern and the table format information. Therefore, it becomes possible to easily add a table to be analyzed.

[0012]

DESCRIPTION OF THE PREFERRED EMBODIMENTS FIG. 1 is a flow chart showing a method of grasping the update history of a relational database according to the present invention. In the figure, S means a step.

First, the name of the output target table (program whose update history is to be grasped) and the key data for identification are grasped (S101). Then, one item is read from the DB2 log analysis file 1 (S102).

The DB2 analysis log file 1 is an update record of the DB collected to restore the DB when the trouble occurs. Its format is as shown in FIG. 2, and its structure is "DB2 relative address", "table name",
It consists of "update category", "plan name" and "table data".

As a procedure for creating the DB2 log analysis file 1, a table based on DB2 (as is well known, data is represented by a table in a relational database) is set corresponding to each of a plurality of programs,
On the other hand, log files (D
B2 Archive log) is created.

Then, only the table for which the log is desired to be referred to is edited as a DB2 log analysis file and output as a sequential compression file. As a result, the processing of the present invention described below can be executed at any time.

With respect to the contents of the read log table, it is judged whether or not key data is collected (S1).
03). At this time, the entire updated row (record) is not collected, but only the area between the first update item and the last update item. When it is determined in step 103 that there is no key data, as shown in FIG. 2, when there is no key data in this log data, the key data output to other log data is searched from the relative address and added ( 2A) (S104). In addition, step 1
If the collection of key data is confirmed in 03, step 1
The processing of 04 is not performed.

Then, it is determined whether the input data is the table and key for which the analysis instruction is made this time (S10).
5). If it is the designated table and key, the list edit processing of the target table is linked (S10).
6). The list editing process differs for each table. This processing is held outside the program, and only the necessary amount is judged at the time of execution and dynamically linked.

After that, the list is edited (S107).
The file-by-file update item list creation processing program is automatically created. The result is output as a list as shown in FIG. 3 (S108). As is apparent from FIG. 3, according to the present invention, the item name is displayed together with the data content, and the content can be immediately grasped without considering the start position and the length unlike the conventional case.

The data is displayed by arranging the data before and after the update in two rows above and below, and displaying only the updated items. The list contents are stored in the DB2 log file 2. If the table and the key are not designated, the process ends.

FIG. 4 is a flow chart showing details of the processing in step 106 shown in FIG.

First, it is determined whether or not the data before and after the update process are the same (S401). If they are the same, the process proceeds to step 107, but if they are not the same, the data name of the target item is set to be output (S40).
2). Next, data is set following the data name of the target item (S403), and further edited in the output format (S404). The processing from step 401 to step 404 is performed for all items in the target table.

By the way, in implementing the present invention, a program for editing a list for each table to be analyzed is required. By automatically generating this program, the table to be analyzed can be added easily.

FIG. 5 is a flowchart showing the file-by-file update item list creation process.

First, the member name of the table format (record definition) is designated (S501). Then, based on the processing pattern file 3 (where the editing logic is stored) and the table format file 4 (where the table structure is stored), list editing (processing statement automatic generation and edit output data area) is automatically generated. Perform (S502).

The automatic processing statement generation generates the pattern logic for each item of the table format of the table format file 4. At this time,
The statement part of the pattern logic (for example,
(The part indicated by the "&" symbol) is converted to a table format item name.

Further, it is determined where to embed in the skeleton of the logic embedded skeleton file 5 (corresponding to the skeleton of the program) with a specific name (for example, "* COPY =") in the generated logic, Insert (S503). This is stored in the list edit program source file 6.

[0028]

Since the present invention is constructed as described above, it has the following effects.

In the method of grasping the update history of a relational database according to claim 1, a file formatted as a log analysis file only for the table to be referred to in the log file in which the access information from all programs to the relational database 2 is recorded. On the other hand, the output target table name and output target key are specified and the list is edited, and the updated data name is output together with the data content, so the update history can be grasped quickly and accurately, and the consistent flow test can be performed. It is possible to improve the quality in.

In the method for grasping the update history of the relational database according to claim 2, since the means for automatically generating the program for editing the list for each table to be analyzed is provided, the table to be analyzed can be easily added. It will be possible.

[Brief description of drawings]

FIG. 1 is a flowchart showing a method for grasping an update history of a relational database according to the present invention.

FIG. 2 is an explanatory diagram showing a format of a DB2 analysis file.

FIG. 3 is an explanatory diagram showing output contents of a log analysis list according to the present invention.

FIG. 4 is a flowchart showing details of the process in step 106 of FIG.

FIG. 5 is a flowchart showing a file-by-file update item list creation process.

FIG. 6 is an explanatory diagram showing a table format used in conventional update grasping.

FIG. 7 is an explanatory diagram showing log data as a conventional update grasping result.

[Explanation of symbols]

 1 DB2 analysis file 2 DB2 log file 3 Processing pattern file 4 Table format file 5 Logic embedded skeleton file 6 List editing program source file

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Isao Sakurai 1 Kimitsu, Kimitsu-shi, Chiba Nippon Steel Information & Communication Systems Co., Ltd. Kimitsu branch office (72) Inventor Kenji Nunome 1 Kimitsu, Chiba Shin Nippon Steel Co., Ltd. Kimitsu Works

Claims (2)

[Claims] 1. An output target table name and an output target key are assigned to a file formatted as a log analysis file only for a table to be referred to in a log file in which access information from all programs to the relational database 2 is recorded. A method of grasping the update history of a relational database, which is characterized by performing list editing by specifying and outputting the updated data name together with the data content. 2. The method for grasping the update history of a relational database according to claim 1, further comprising means for automatically generating a program for editing a list for each table to be analyzed.