JPH0619756A - EDI format conversion method - Google Patents

Abstract

(57) [Summary] [Purpose] Just by changing the condition settings for projection processing,
It is an object of the present invention to provide an EDI format conversion method capable of freely changing the item layout of a user-specific database. [Configuration] User-specific data read from the user-specific database 11 or received EDI standard data is stored in R
Data derivation units 12 and 25 for deriving in a table structure on the DB pseudo tables 13 and 26, and columns pre-specified from the RDB pseudo tables 13 and 26 are extracted on the output table 15 and the update table 28 to project the projections. Data extractor 14, 27
And the data of each row of the table structure held in the output table 15 is externally transmitted as EDI standard data after the format conversion, and the data of each row of the table structure held in the update table 28 is unique to the update user after the format conversion. Process as data.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to ED in data transmission between computers connected through a network.
The present invention relates to an EDI format conversion method for performing format conversion between standard data and user-specific data.

[0002]

2. Description of the Related Art Conventionally, several EDI (Electronic D) have been used as a business protocol for smoothly transmitting data between computers of different models or between users of different industries.
ata Interchange) rules have been established. This EDI
The data standardized according to the rules is referred to as EDI standard data here. When such an EDI method is introduced, a translator that performs format conversion between data in a database owned by the user (user-specific database) and EDI standard data is an essential element in each computer.

However, the item layout of the user-specific database varies from user to user, and it is often necessary to change the translator for each user. It is also necessary for the same user to create a different translator for each transmission task. Further, the translator must be modified when the transmission work process between users is changed or the EDI rule is changed or strengthened.

Thus, the translator changes frequently,
Has a fate to be modified. However, in order to correct the translator, the source program had to be changed even with a very simple correction, and there was a problem that the work required a great deal of work.

[0005]

As described above, conventionally, the modification of the translator for performing the format conversion from the user-specific data to the EDI standard data or from the EDI standard data to the user-specific data requires the change of the source program. , There was a problem that the correction work takes time.

The present invention is intended to solve such a problem, and an EDI format conversion method capable of freely setting and changing the item layout of a user-specific database only by changing the condition setting of the projection processing and the like. The purpose is to provide.

[0007]

In order to achieve the above-mentioned object, the EDI format conversion method of the first invention is a method for converting user-specific data into an EDI standard data format. And a step of deriving the read user-specific data in the form of a table structure on a first table simulating a relational database,
Extracting a column corresponding to an item constituting the EDI standard data from the table structure held in the first table according to a predesignated condition and projecting the column onto the second table; The step of externally transmitting the data of each row of the table structure held in the table as EDI standard data after format conversion.

In order to achieve the above object, the EDI format conversion method of the second invention is a method of converting EDI standard data into a format of user-specific data, the step of receiving the EDI standard data, and the received ED.
A step of deriving I standard data in the form of a table structure on a first table simulating a relational database;
Extracting a column corresponding to an item constituting the user-specific data from a table structure held in the first table according to a predesignated condition and projecting the column onto the second table; And outputting the data of each row of the table structure held in the table as user-specific data after format conversion.

[0009]

In other words, in the first invention, the user-specific data read from the user-specific database is derived in the form of a table structure on the first table simulating the relational database, so that the user-specific data can be stored in the data structure. Replace with a format that can be converted. Then the first
Columns corresponding to the items that make up the EDI standard data are extracted from the table (1) and a new table structure is projected on the second table. The condition for retrieving the column to be projected is given by the user in advance by an SQL (Structured Query Language) statement. Next, the data of each row of the table structure held in the second table is externally transmitted as EDI standard data after format conversion.

In the second invention, when the EDI standard data is received from the outside, the received EDI standard data is derived in the form of a table structure on the first table simulating the relational database, so that the EDI standard data is obtained. Replace with a format that can withstand data structure conversion. Next, the columns corresponding to the items forming the user-specific data are extracted from the first table, and the new table structure is projected on the second table. The condition for searching the column to be projected is given in advance by the user as an SQL statement. Next, the data in each row of the table structure held in the second table is output as the format-converted user-specific data.

As described above, according to the EDI format conversion method of the present invention, the format conversion between the user-specific data and the EDI standard data is performed by using the projection processing which is a basic function for the relational database. Therefore, the item layout of the user-specific database can be freely set and changed only by changing the condition setting of the projection process.

[0012]

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

FIG. 1 is a block diagram for explaining the configuration of a data transmission system adopting an EDI format conversion method according to an embodiment of the present invention.

In the figure, 10 and 20 are computers connected through a network 30. Connected to each of the computers 10 and 20 are user-specific databases 11 and 21, which are databases in which the user defines the record (item) layout in record units. Where 10 computers are senders, 20
Each computer 10, 2 as the receiving side
The configuration of 0 will be described. In the computer 10 on the transmitting side, 12 is transaction data, which is user-specific data read from the user-specific database 11,
Relational database (hereinafter referred to as RDB)
It is a data derivation unit that derives on the RDB pseudo table 13 using the projection function of. 14 is an RDB pseudo table 13
Is a data extraction unit that extracts columns (conditions) specified in advance by the user from the table structure of FIG. 3 and projects a new table structure corresponding to the format of the EDI standard data on the output table 15. 16 is the output table 1 when the user-specific data and the EDI standard data have different code systems.
5 is a code conversion unit for converting the data held in No. 5 into the code system of EDI standard data. 17 is the output table 1
The data read in row units from the table structure of 5 is E
It is a transmission processing unit that transmits to the network 30 as DI standard data.

On the other hand, in the receiving-side computer 20, reference numeral 22 is a reception processing unit for receiving the EDI standard data transmitted by the computer 10 from the network 30.
Reference numeral 23 represents the received EDI standard data in SQL (Structured
Query Language) This is a conversion unit that converts normalized fixed length data that can be referenced. Reference numeral 24 is a normalized fixed-length file that stores the normalized fixed-length data obtained by the conversion unit 23. Two
5 is the EDI read from the normalized fixed length file 24
It is a data derivation unit that derives standard data on the RDB pseudo table 26 using the projection function of RDB. 27 is R
This is a data extraction unit that extracts columns (conditions) specified by the user in advance from the table structure of the DB pseudo table 26 and projects a new table structure corresponding to the format of the user-specific data on the receiving side onto the update table 28. . 29
Is a code conversion unit that converts the data held in the update table 28 into the code system of the receiving-side user-specific data when the EDI standard data and the receiving-side user-specific data have different code systems.

Next, the operation of the data transmission system of this embodiment will be described. FIG. 2 is a flowchart showing a processing procedure at the time of data transmission in the computer 10 on the transmission side.

First, in the computer 10 on the transmitting side,
The transaction data for updating is read from the user unique database 11 and passed to the data deriving unit 12 (step 201). The data deriving unit 12 determines the contents of the data dictionary in the user-specific database 11,
That is, based on the names, numbers, sizes, etc. of the items (fields) that make up the transaction data (record), for example, as shown in FIG. 3, a plurality of columns (columns) C1, C2, C3 corresponding to the respective items, C4 is set in the RDB pseudo table 13, and the corresponding item in the transaction data is assigned to each column C1, C2, C3, C4 of the RDB pseudo table 13 using the projection function of RDB (step 202).

Next, the data extraction unit 14 selects from the table structure of the RDB pseudo table 13 as shown in FIG.
The columns C1, C3, and C4 that have been conditionally specified by the user are extracted and a new table structure is projected on the output table 15 (step 203). The condition for searching the column to be projected is given in advance by the user as an SQL statement according to the format of the EDI standard data.

If the code systems of the user-specific data and the EDI standard data are different (step 20).
4) As shown in FIG. 5, the code conversion unit 16 fetches the data from the output table 15 into the internal code conversion work area 51 and creates a code correspondence table (not shown) between the user-specific local data and the EDI standard data. It retrieves and converts the user-specific local data into the EDI standard data code system (step 205). After converting the code system in this way, the data of the output table 15 is transmitted to the network 30 by the transmission processing unit 17 (step 20).
6). When all data has been transmitted (step 20)
7), the process on the computer 10 side ends (step 208).

Next, the processing procedure of the receiving side computer 20 will be described with reference to the flowchart of FIG.

In the reception processing section 22 of the computer 20, E
When the DI standard data is received (step 601), the conversion unit 23 converts the received EDI standard data into normalized fixed length data. That is, the EDI standard data is divided into items that are compatible with the projection process on the receiving side and normalized, and the items are converted into fixed length data (step 60).
2). This conversion is performed by converting the structure information (name, number, size indicating the attribute of the item) of the EDI standard data transferred from the computer 10 prior to the reception of the EDI standard data and the data registered in the user-specific database 21 on the receiving side. It is performed based on the contents of the dictionary, for example, the name, number, and size of items indicating the attributes of the receiving-side user-specific data. Then, the normalized fixed length data after conversion is stored in the normalized fixed length file 24 (step 603).

When all the transfer data have been stored in the normalized fixed length file 24 (step 604), the data deriving unit 25 stores the EDI standard stored in the normalized fixed length file 24 as shown in FIG. A plurality of columns C5, C6, C7, C8 corresponding to respective items of data are set on the RDB pseudo table 26, and the RDB pseudo table 2
The data of the corresponding item in the EDI standard data is assigned to each of the columns C5, C6, C7, C8 of 6 (step 605).

Next, as shown in FIG. 8, the data extraction unit 27 extracts columns C5, C6, C7, C8 which are pre-specified by the user from the table structure of the RDB pseudo table 26 and creates a new table. The structure is projected on the update table 28 (step 606). The condition for searching the column to be projected is given in advance by the user as an SQL statement according to the format of the EDI standard data. At this time, the setting of the columns on the update table 28 is based on the contents of the data dictionary registered in the user-specific database 21 on the receiving side.

Here, if the receiving side user-specific data and the ED
I If the code system differs from the standard data (step 6)
07), the code conversion unit 29 takes in the data from the update table 28, and converts this data into the code system of the receiving side user unique data using the internal conversion work area (step 608).

After the conversion of the code system in this way, the data of the update table 28 is used for the user-specific database 21.
The corresponding file in step S609 is updated (step 609), and the processing of the receiving computer 20 ends (step 61).
0).

In this embodiment, the case where one transaction data is derived on the RDB simulation table 13 by the data deriving unit 12 of the transmission side computer 10 has been described. When it is read, the processing is performed as follows.

That is, as shown in FIG. 9, the data deriving unit 12 prepares a plurality of RDB pseudo tables 13a, 13b, ..., 13c according to the number of transaction data, and the respective RDB pseudo tables 13a, 13b,
..., a plurality of columns C1 to C12 corresponding to the item structure of each transaction data are set on 13c. And each RD
The corresponding items of each transaction data are assigned to the respective columns C1 to C12 of the B pseudo tables 13a, 13b, ..., 13c. Next, the data extraction unit 14 determines each R
.., 13c are extracted from the DB pseudo tables 13a, 13b, ..., 13c, and the columns C1, C2, C8, C12 specified in advance are extracted and combined into one output table 15.

Further, in this case, on the receiving side, as shown in FIG.
As shown in 0, the RDB pseudo table 26 is projected to the plurality of update tables 28a, 28b, ... And the plurality of corresponding files 21 in the user-specific database 21.
a and 21b are updated with the data of the update tables 28a and 28b.

Thus, according to the data transmission system employing the EDI format conversion method of this embodiment, the RDB
User-specific data and E
It is possible to perform format conversion with DI standard data. Therefore, when the user changes the item layout of the user-specific databases 11 and 21, at the same time, the user only has to change the condition setting of the projection process by the SQL statement and the definition of the data dictionary of the user-specific databases 11 and 21.

In the present embodiment, the code system conversion processing is performed after the projection processing from the RDB simulation tables 13 and 26 to the output table 13 and the update table 28 is performed, but the RDB simulation tables 13 and 26 are performed. May be performed during the projection processing from the output table 13 to the update table 28, that is, before the projection data is transferred to the output table 13 and the update table 28.

In this embodiment, the computer 10 is described as the transmitting side and the computer 20 is as the receiving side.
It goes without saying that each of the computers 10 and 20 may have all the configurations of the transmitting side and the receiving side in FIG.

[0032]

As described above, according to the EDI format conversion method of the present invention, the format conversion between user-specific data and EDI standard data is performed by using the projection processing which is a function of the relational database. You can Therefore, the user can freely set and change the item layout of the user-specific database simply by changing the condition setting of the projection process.

[Brief description of drawings]

FIG. 1 is a block diagram illustrating a configuration of a data transmission system that employs an EDI format conversion method according to an embodiment of the present invention.

FIG. 2 is a flowchart showing a processing procedure of a transmitting side computer in the data transmission system of FIG.

FIG. 3 is a diagram for explaining a data derivation process of a sending computer in FIG.

FIG. 4 is a diagram for explaining a projection process of a transmission side computer in FIG.

5 is a diagram for explaining a conversion process of a code system between user-specific data and EDI standard data in FIG.

6 is a flowchart showing a processing procedure of a receiving computer in the data transmission system of FIG.

FIG. 7 is a diagram for explaining the data derivation process of the receiving computer in FIG.

FIG. 8 is a diagram for explaining the projection process of the receiving computer in FIG.

FIG. 9 is a diagram showing a derivation process and a projection process of a sending computer for a plurality of transaction data.

FIG. 10 is a diagram showing a derivation process and a projection process of a receiving computer for a plurality of transaction data.

[Explanation of symbols]

10 ... Transmission side computer, 11 ... User specific database, 12 ... Data derivation unit, 13 ... RDB pseudo table, 14 ... Data extraction unit, 15 ... Output table, 16 ...
Code conversion unit, 17 ... Transmission processing unit, 20 ... Receiving side computer, 21 ... User unique database, 22 ... Reception processing unit, 23 ... Conversion unit, 24 ... Normalized fixed length file,
25 ... Data derivation unit, 26 ... RDB pseudo table, 27
... Data extraction unit, 28 ... Update table, 29 ... Code conversion unit.

Claims (3)

[Claims] 1. A method for converting user-specific data into a format of EDI standard data, a step of reading the user-specific data from the user-specific database, and a first table simulating the read user-specific data in a relational database. The step of deriving in the form of a table structure above, and extracting the columns corresponding to the items constituting the EDI standard data from the table structure held in the first table according to a prespecified condition And a step of externally transmitting the data of each row of the table structure held in the second table as EDI standard data after format conversion. 2. A method of converting EDI standard data into a format of user-specific data, a step of receiving EDI standard data, and a table structure of the received EDI standard data on a first table simulating a relational database. And the column structure corresponding to the items constituting the user-specific data is extracted from the table structure held in the first table according to a prespecified condition and projected onto the second table. An EDI format conversion method comprising: a step of outputting the data of each row of the table structure held in the second table as user-specific data after format conversion. 3. The EDI format conversion method according to claim 2, further comprising the step of converting the received EDI standard data into normalized fixed-length data.