JP3048181B2 - Update processing method for relational database with history information - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of updating a relational database with history information, and more particularly, to a relational database (hereinafter abbreviated as RDB) in a case where an object to be updated varies by month, organization, or the like. Application in the update processing method of
RDB incorporating a mechanism for realizing data-centric transaction processing separately from the AP and a mechanism for securing the performance as a transaction by compiling the transaction description in advance and performing a static operation. Update processing method.

[0002]

2. Description of the Related Art In the conventional AP design, an attempt has been made to improve the productivity of a component-oriented system by developing an AP corresponding to a business and converting a common part between the APs into a subroutine. For access to RDB,
Table name is described in the AP,
did not exist.

However, as the construction of information systems using RDBs has progressed, so-called R
Problems such as the influence on the performance conditions that become apparent with the configuration of the DB, the consistency of the update processing, and the consistency have been greatly affecting the improvement in productivity.

[0004] The same column structure is used in units of years, organizations, etc.
In a DB structure divided into separate tables,
Developing an AP that is aware of the table to be accessed
It leads to a drop in productivity. For this reason, productivity improvement is particularly desired with the update of the RDB in which the update target is variable such as by organization or by month.

A conventional RDB update processing method will be described with reference to FIG.

In FIG. 8, a host language embedded database access language (hereinafter abbreviated as SQL) description application group 11 and 12 is a relational database management system (hereinafter abbreviated as DBMS) 15.
A search and update event from each application group is performed on the table group 16 accessed via the. Here, the database access language (S
QL), which is pre-compiled in a transactional manner to improve runtime performance.

[0007]

In the conventional RDB update processing method, since the RDB update processing is constructed for each business according to many patterns, consistency between transactions among many programmers, search update, and so on. conditions with the avoidance of conflicts between each application must be resolved in each AP in terms of influence of performance conditions, also operate
(Eg, year change, organization change, etc.)
Changing the configuration of B affects the AP (for example,
(Change of the described SQL).

[0008] The present invention has been made in view of the above,
It is an object of the present invention to provide a relational database update processing method with history information that incorporates a mechanism for designing transactions in a data-centric manner without sacrificing the performance of conventional transaction processing.

[0009]

Means for Solving the Problems] To achieve the above object, the update processing method of the relational database with history information of the present invention, in vertical distributed redundant database environment of the local system and the center system, the center system / local
System database update synchronization takes place within a transaction.
History information for separate transactions
Relays update information to each system's database based on the
In the synchronous update process of the
History within a transaction, independent of the application
Host language embedded database with information acquisition
Update log common to systems that perform access language application update processing
A transaction application and said application
Data corresponding to various events from the database
Received as a parameter for access,
System update transaction application
A driver interface that inherits parameters is provided.
The update transaction application common to the system
Options correspond to the update support type and event type.
An access target determination unit that determines an update target table;
History information that stores update history information corresponding to the type of new target
From the driver interface.
Parameter, and based on this parameter,
Output search instruction of update target table to access target determination unit
In addition, the history information editing processing unit
Instructed to output history information and updated the type corresponding to the acquired update target
A table that updates and stores the target table based on the history information
And an update processing unit corresponding to the table.

[0010]

According to the relational database update processing method with history information of the present invention, the data access portion common to the APs, the distribution to the access target table group, and the portion related to the history information are black-boxed on the software configuration, and the BOX is defined between the portions. The linkage section inherits pointers from the main program, pointers to the database access part are statically described in SQL to satisfy the conventional performance conditions, and productivity is achieved by creating execution modules up to the machine language level by compiling in advance. In addition, take advantage of performance improvements.

[0011]

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

FIG. 1 is a schematic diagram showing a software configuration for implementing a relational database (RDB) update processing method with history information according to an embodiment of the present invention. In the figure, in response to application group 1, each table 6 the RDB that implements the business, the actual processing logic part table search update is separated from the AP tape
Table corresponding update processing unit 3 to realize the table corresponding update.
Processor accessed from within 3, i.e. by year, and the access object determining unit 4 performs the determination of the access target in the tissue related footwear
As a form of calling the history information editing processing unit 5 , the history information editing processing unit 5 is completely hidden from the application group.

An external control table 7 is provided for actually mapping logical information (event information, data, year-by-year, organization-related information, etc.) visible to the application to the RDB structure.

Further, a driver 2 is provided to make the application interface the same and to transfer control to the common transaction AP of each table corresponding update processing unit 3 .

As is clear from the comparison with FIG.
With regard to the B update processing method, the application interface is simplified by specializing in the conventional RDB access, being independent of the application, and further interposing a driver.

Next, with reference to the flowcharts shown in FIGS. 2 to 5, an outline of the AP, driver, and RDB update processing related to the RDB update processing method will be described.

FIG. 2 shows a process in which an application inputs a message directly from a terminal and the process is based on the message content. First, when a message is directly input from the terminal (step 11).
0), the application checks in advance whether the content of the message is within the range of the specified value with respect to the validity of the attribute (step 120), and based on the value of each field in the message, the driver shown in the table of FIG. set the value in the driver parameters for the interface (step 130), dry
Call the bus 2 (step 140). Next, the driver
Business content processing based on the processing result of 2 (normal / abnormal)
(Step 150) is performed. Note that the process
In order to unify the judgment of the processing result of driver 2,
As a result, it has a return code at the beginning of the parameter.

Next, when the entire process is completed with the business content processing result of step 150, the update information and the history information of the database of the business content processing of step 150 are reflected on the actual medium from the input of the message of step 110, or A rescue declaration is made to discard the abnormal processing update information and the history information from the message input in step 110 to the business content processing in step 150 (step 16).
0). Then, the terminal message is edited according to the success or failure of the rescue declaration, and the normal and abnormal message is transmitted and output to the terminal (step 170).

Next, the processing of the driver 2 shown in FIG. 3 will be described. In FIG. 3, first, the range of the value of the parameter received from the application and the key identification pattern are checked (step 210), and D corresponding to the processing target table name in the P2 parameter shown in the table of FIG.
As the B update processing , a table corresponding update processing 3 is called (step 220). This call is set in the COBOL linkage section in order to delete the parameter move processing, and the parameter is directly transferred from the application to the DB update processing.

Next, the DB update processing shown in FIG. 4 will be described. FIG. 4 shows an actual database access via SQL for searching, adding, and deleting a database, or various history information associated with addition, update, and deletion ( FIG. 6 ) .
Items corresponding to P2, P3, and P4 parameters in the table above )
9 is a flowchart showing processing contents for performing control for acquiring history information by editing.

In FIG. 4, first, a parameter check is performed to check the consistency of the target table (steps 310 and 320). This is performed by verifying the correspondence between the number of update columns, the update column name group, and the update column value group. Then, according to the processing type and the key pattern from the contents of the parameter P2 in the table of FIG.
Call the processing routine (steps 330 and 34)
0).

Next, at step 350, the key pattern
SQL processing unit for key pattern 1, SQL processing for key pattern 2
Any of the SQL processing units of the key pattern n
Performs the processing target SQL processing by Kano key pattern. Since the processing in step 350 is shown in detail in FIG. 5, it will be described with reference to the flowchart in FIG. In FIG. 5, it has already been described in the program.
To take the correspondence and updating the column names taken over by the host variables and parameters corresponding to each column name RDB, outer
With reference to the part definition table 7 , correspondence between the corresponding host variable name and the updated column name is determined (step 410). At this time, external
The definition table 7 is entered in ascending order so that updated column names of each table can be identified at high speed, and can be searched by a binary search. Note that the actual SQL
Although the host variable which is a variable area of data transfer between the and the relational DBMS is determined, the update column coming from the message input is not always associated with the order of the host variable, so the host variable The update value specified as the host variable is set by having the correspondence information between the and the update column name as the external control table 7 (step 420). Then issue an update SQL
(Step 430) Return code after SQL issuance
Is determined / set (step 440).

Returning to FIG. 4, in step 360, FIG.
It is determined whether to call history information acquisition based on the presence or absence of the history of the P2 parameter in the table shown in FIG. Then, history information is acquired based on the P2, P3, and P4 parameters in the table (step 370). Note that the history information is obtained in a file block according to the organization code in the P2 parameter in the table ,
The change history makes it easy to edit information for the organization. Then, a return code and a search result are set (step 380).

All parameters relating to the table shown in FIG. 6 exist as a part of the contents of a message when the message is input . However, the number of update columns is necessary only when the processing type is D or U, and the update column group and the update value group are required only when the processing type is U.

As can be seen from the above, a pure AP can update a database without being aware of the physical structure of the database.
Becomes possible.

FIG. 7 shows a key identification pattern (key pattern).
This clearly shows how to determine

Here, the key identification pattern is a key pattern at the time of search / update which becomes clear by focusing on the access event of the business to be updated in advance in correspondence with the table (that is, by performing business analysis centering on the database ) . , Search / update conditions of table target search / update processing corresponding to this key pattern, SELECT, U in SQL
WHERE such as PDATE, INSERT, DELETE
A conditional clause such as an E condition is generated.

Therefore, when the database design is completed, a design method completely separate from the AP can be applied, and the AP can be designed with only logical and business information in mind.

Further, as a result of performing a business analysis as a transaction in advance, it is possible to predetermine processing corresponding to a key pattern, and thus it is possible to statically compile and satisfy performance conditions.

Further, as is clear from the comparison from FIG. 8, all the items of the driver interface are included in the contents of the message input items, and the AP completely tunes the parameter transfer from the message contents to the driver and the operation. Have done the content.

Therefore, the AP designer can adopt a structure that is not affected by the performance, the DB update consistency, the table change, and the like.

As mentioned above, the AP is a normalized DB
Just be aware of the structure.
The difference is absorbed. This is a DB design technique
Performs denormalization of DB structure taking into account the stated performance.
Even if this is done, the effect on the AP (DB integrity
Data-centric DB design (correct
Standardized DB) and AP design based on it
You.

[0033]

As described above, according to the present invention,
By effectively utilizing the RDB design technique, transaction type RDB access common to the AP and separated can be achieved, and the following effects can be obtained.

(1) In the transaction type construction method described in the AP, the following system conditions, in which the specific design contents in the database design / construction / maintenance process affect the entire AP program group, are separated from the AP. The number of design / test man-hours required for this can be greatly reduced.

[0035] Effect of change when performance conditions such as search / update of RDB are not satisfied. Mechanism for checking update consistency of RDB that has been straddling between conventional APs. Influence of structure change such as RDB reconfiguration (2) AP and RDB accesses are virtualized by the driver interface. Therefore, when expansion such as adding a table in the future, the AP does not particularly affect the RDB update processing unit. It affects only the driver unit having an interface with the common processing unit corresponding to the table and the RDB update processing unit. Obedience
As a result, it is possible to construct a system that is highly expandable.

Also, for example, in units of year, month, organization, etc.
DB structure divided into different tables with the same column structure
The AP can update the DB without being aware of the differences between the tables.
Can be new.

(3) The present invention uses a vertical dispersion type and a part of RD
It is necessary to construct the AP in a configuration in which the tables in B have overlapping data in a vertically distributed form, and thus eliminate the inconsistency of data by concealing the configuration conditions of the RDB specialized for the system from the AP. It is possible to do.

(4) In the future, the common processing unit under the driver interface as viewed from the AP will be a multi-processor server that assigns a processor to each table group, using the driver as a client.
With this software configuration, the transition can be made flexibly.

That is, the RDB configured for each table
The update processing common unit can also be applied to a hardware configuration that can run in parallel under the multiprocessor.

[Brief description of the drawings]

FIG. 1 shows an RD with history information according to an embodiment of the present invention.
It is the schematic which shows the software structure which implements B update processing method.

FIG. 2 is a flowchart illustrating processing of an application.

FIG. 3 is a flowchart illustrating processing of a driver.

FIG. 4 is a flowchart illustrating an RDB update process.

FIG. 5 is a flowchart showing an SQL process to be processed by a key pattern.

FIG. 6 is a table showing parameters of a driver interface in the RDB update processing method.

FIG. 7 is a table showing a method for determining a key identification pattern.

FIG. 8 is a configuration diagram of a conventional RDB update processing method.

[Explanation of symbols]

 Reference Signs List 1 application group 2 driver 3 table correspondence update processing unit 4 access target determination unit 5 history information editing processing unit 6 relational database table 7 external control table

──────────────────────────────────────────────────続 き Continuation of front page (56) References JP-A-3-5846 (JP, A) NTT R & D VOL. 38 No. 5 (1989), Telecommunications Association of Japan, Yoshikazu Kishimoto et al. 565-572 (58) Field surveyed (Int. Cl. ⁷ , DB name) G06F 12/00 G06F 17/30

Claims (1)

(57) [Claims] 1. In a vertically distributed overlapping database environment comprising a local system and a center system, data of a center system / local system is
Database update synchronization is not possible within a transaction
For separate transactions, based on history information
A relationer that reflects update information in each system database
In the database update synchronization process, independent of the application, within the transaction
Language database with acquisition of history information
Update common to all systems that perform source access language application update processing
A new transaction application and data corresponding to various events from the application
Data as parameters for database access
Receiving the update transaction application common to the system
Driver in the application
And an update transaction application common to the system.
The update target table corresponds to the update type and event type.
Access target determination unit that determines the table, and history information that stores update history information corresponding to the type of update target
An editing processing unit for receiving the parameter from the driver interface;
The access target is determined based on this parameter.
Output a search instruction for the table to be updated to the
Output the history information to be updated to the history information editing processing unit
Instructed and based on the acquired update history information corresponding to the type of update target
Table update that updates and stores the target table
Relational database update processing method with history information, characterized by comprising a processing unit.