JP2008243193A - Data management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data management system for general purposely performing data exchange/data conversion between different types of systems, between different types of package software, between different types of infrastructures. <P>SOLUTION: The data management system stores item definition information for system for respectively defining profiles of data items of different systems, item definition information for a standard profile for covering the whole item definition information for system of management objects, and item related definition information for defining a correspondence relation between the item definition information for system and the item definition information for a standard profile, uses the item definition information for system, the item definition information for a standard profile and the item related definition information to automatically convert a data item of export data according to one system profile between two different systems into a data item according to the other system profile. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a data management system, and more particularly to a data management system suitable for exchanging data of various formats.

Conventionally, as this type of technology, for example, there is a technology described in Patent Document 1.
JP 2003-208382 A

  Patent Document 1 discloses that each EDI user company does not burden the data format conversion of the EDI standard format data into the EDI user user company internal format data and the inverse conversion thereof, and the data format conversion is performed on the Internet. A data format conversion method and system between EDI-using user companies, which are performed on the above specific site, are disclosed. In this system, data transmission / reception between EDI-using user companies is performed using the respective in-house format data. Specifically, in this system, when there is in-house format data from a user company to a user company via the Internet on the electronic commerce site, the data is based on pre-registered data conversion profile information corresponding to the user company, Once converted to EDI standard format data, it is further converted to in-house format data of the user company based on the pre-registered data conversion profile information corresponding to the user company, and then transmitted to the user company via the Internet. The This technology is a mechanism that allows existing mapping tools to function on the Internet, and can be used by each company mapping their individual formats to industry standard formats.

  However, the technique described in Patent Document 1 cannot be used when a supplier company does not use it. Further, Patent Document 1 does not have specific data storage or data conversion description, and has always been in external design. In addition, data transmission / reception between EDI-using user companies is made symmetric, and in the present situation where the use of EDI standard format data is small, companies that can be used are greatly limited.

  SUMMARY OF THE INVENTION An object of the present invention is to provide a data management system that can exchange data of various formats with each other and can easily cope with addition and change of the data format of management target data.

  The data management system according to claim 1 includes system profile item definition information that defines data formats of different systems (for example, constituted by corresponding portions of a column management table described later), and all systems to be managed Item definition information for the standard profile covering the item definition information (for example, composed of a corresponding part of a column management table described later), item definition information for the system profile, item definition information for the standard profile, Item-related definition information that defines the correspondence relationship (for example, configured by a corresponding portion of an item-related definition table described later), item definition information for the system profile, item definition information for the standard profile, and Of the two different systems using the item related definition information Data items exported data in accordance with the profile of one of the system automatically converts the data items of import data in accordance with the profile of the other system.

  According to a second aspect of the present invention, in the data management system according to the first aspect, at least a column ID that uniquely indicates each data item of the system and a column ID that uniquely indicates each data item of the standard profile are defined in advance. A column management file that is stored statically and stores the item definition information for the system profile and the item definition information for the standard profile in the column management file, and uniquely indicates each data item of the system An item relation definition file that predefines a correspondence relationship between an ID and a column ID that uniquely indicates each data item of the standard profile and stores it statically, and stores the item relation definition information in the item relation definition file .

  The data management system according to claim 3 defines the correspondence relationship between the item definition information for the system profile, the item definition information for the system profile, and the item definition information for the standard profile in the configuration of claim 1 The item-related definition information for the system profile to be stored on the network as a pair, and the item definition information for the system profile of any at least two systems and the system profile according to a user request The item related definition information for the system profile is downloaded, and the downloaded item definition information for the system profile and the item related definition information for the system profile are paired with the item definition information for the standard profile. One of the at least two systems Data items exported data according to system data format, automatically convert data items of import data in accordance with the data format of the other system.

  A data management system according to claim 4 is a data management system that performs data conversion between target data having different data formats, for example, from first target data (pre-conversion data to export data) having a first data format. A data management system that performs data conversion into second data (converted data or imported data) having a second data format different from the first data format. This data management system includes a system profile, a standard profile, item related definition information, a row management file, and a value management file. The system profile is created for each target data to be converted, and stores a column ID that uniquely indicates (or uniquely identifies) a data item that constitutes a record of each target data. Define the format. For example, the system profile corresponds to a corresponding portion of a column management table described later, and can be embodied as, for example, the unique data profiles 1252 and 1262 in FIG. The standard profile stores data items covering all data items of all the target data together with a column ID uniquely indicating the data item, and defines a standard data format of the target data. The standard profile can be embodied as, for example, an SXP standard profile 1250 in FIG. The item relation definition information corresponds to the correspondence between the data item of each system profile and the data item of the system profile in the standard profile and the conversion process (for example, according to the system function defined in the function management table described later) Process). The item related definition information can be embodied as, for example, conversion definitions 1251 and 1261 in FIG. When the record of the target data is read, the row management file stores a row ID uniquely indicating the read record in correspondence with the read record. The row management file can be embodied as, for example, a row management table described later. When the value management file reads the record of the target data, the field value of the data item of the read record, the row ID that uniquely indicates the read record, and the data item in the read record stored in the column management file It is uniquely identified and stored by the column ID corresponding to the value data item. The value management file can be embodied as, for example, a value management table described later. Then, the data management system sets the data format of the target data that is the conversion source (for example, when transmitting data, the transmission data or the data before conversion) based on the system profile corresponding to the target data. The target data is converted into standard data according to the standard data format of the standard profile based on the item related definition information corresponding to the target data. Further, the data management system determines the data format of the target data to be converted based on the system profile corresponding to the target data, and the conversion source based on the item related definition information corresponding to the target data The standard data converted from the target data to be converted into data according to the data format of the target data at the conversion destination. This process can be embodied as a process by the SXP service system of FIG.

  The data management system according to a fifth aspect of the present invention is the data management system according to the fourth aspect, wherein a part of the data items from the target data of the conversion source is further converted during the data conversion from the target data of the conversion source to the target data of the conversion destination. Extracting values separately, converting the extracted data item values according to a predetermined data format to create and store additional data, and then converting the data from the conversion source target data to the conversion destination target data Occasionally, the stored additional data is compared with newly created additional data during subsequent data conversion to determine consistency between them. For example, such a data management system can be embodied as an SXP service system in FIG.

  The data management system according to a sixth aspect of the present invention is the data management system according to the fourth aspect, further comprising master data from the target data of the conversion source at the time of data conversion from the target data of the conversion source to the target data of the conversion destination. Extract some data item values separately, convert the extracted data item values according to a predetermined data format to create and store master data, and then convert the conversion target data from the conversion target data At the time of data conversion to data, the stored master data is compared with newly created master data at the subsequent data conversion to determine consistency between them. For example, such a data management system can be embodied as an SXP service system (particularly for automatic construction of master data) shown in FIG.

  According to a seventh aspect of the present invention, in the configuration of the fourth aspect, for each of the target data, the data management system according to the seventh aspect corresponds to the system profile specifying information that uniquely indicates the system profile corresponding to the target data, and the target data Common format shared information having at least item related definition specifying information that uniquely indicates the item related definition information to be added, and when the conversion target data is read (for example, when performing network transmission, transmission accompanying reading) Etc.) based on the shared information, determine the system profile and the item definition information corresponding to the target data of the conversion source, and use the corresponding system profile and the item definition information The target data of the conversion source is in the standard data format of the standard profile. Converted into standard data. For example, such a data management system can be embodied as an SXP service system in FIG.

  The data management system according to an eighth aspect corresponds to the configuration according to the fourth aspect, wherein, for each of the target data, transmission source information that uniquely indicates a transmission source of the target data, and target data of the transmission source Source system profile specifying information uniquely indicating the system profile, source item related definition specifying information uniquely indicating the item related definition information corresponding to the target data of the source, and a destination of the target data unique , Transmission destination system profile specifying information uniquely indicating the system profile corresponding to the target data of the transmission destination, and transmission uniquely indicating the item relation definition information corresponding to the target data of the transmission destination Header information consisting of shared information in a common format having destination item related definition specifying information is added. And this data management system performs the following processes at the time of transmission of the conversion target data. That is, the data management system first determines the storage destination of the target data of the conversion source based on the transmission source information of the header information of the target data of the conversion source, and the storage destination selected based on the determination Is stored in the conversion source target data based on the transmission source system profile identification information and the transmission source item related definition identification information in the header information of the conversion source target data. The corresponding system profile and item related definition information are determined, and the conversion source target data stored in the storage destination is used as the standard profile using the system profile and the item definition information selected based on the determination. Is converted to standard data according to the standard data format, and then the header information of the target data of the conversion source is transmitted. Based on the system profile specifying information and the destination item related definition specifying information, the system profile and the item related definition information corresponding to the target data of the conversion destination are determined, and the system profile and the item selected based on the determination Using definition information, the standard data is converted into destination data according to the data format of the target data of the destination, and then based on the destination information of the header information of the target data of the conversion source The storage location of the transmission destination data is determined, and the transmission destination data is stored in the storage location selected based on the determination. For example, such a data management system can be embodied as an SXP service system in FIG.

The data management system of the present invention can be applied to a data management system that uses an arbitrary database such as a hierarchical database, a network database, or a relational database (RDB). When the data management system of claim 1 is applied to a data management system using a relational database (also called a relational database), the column management file becomes a column management table, the row management file becomes a row management table, and value management. The file becomes a value management table. As described above, the present invention is particularly preferably embodied in a database system using an RDB, but of course can be embodied in other databases (DB). Here, in the record to be managed, one record is usually composed of a plurality of fields (a plurality of data items), and in the case of RDB, one row of records may be referred to as a tuple. In general, a plurality of records form one file. In the case of RDB, one file is one table. Each file has a unique data format. In the case of RDB, each table has a unique data format (data structure or schema). In other words, each table has a data format in which unique data items (sometimes referred to as columns or columns, usually a plurality) are arranged.
In addition, the data management system of the present invention uses a code system using an XML tag or the like in addition to an ID according to a code system (code system using numerals or alphanumeric characters) used in a normal RDB or the like as a column ID. The ID by can also be used.

  The data management system according to the present invention can exchange data in a wide variety of formats with each other, and can easily cope with addition and change of the data format of data to be managed.

  Hereinafter, the best mode for carrying out the present invention (hereinafter referred to as an embodiment) will be described. Throughout each embodiment, the same members, elements, or parts are denoted by the same reference numerals, and the description thereof is omitted.

Embodiment 1
FIG. 1 is a block diagram schematically showing a configuration of a sales management system as a data management system according to Embodiment 1 of the present invention. FIG. 2 is an explanatory diagram schematically showing the data structure of the data management system according to the first embodiment of the present invention. FIG. 77 is a block diagram schematically showing the configuration of a sales management system as a conventional data management system.

Conventional sales management system When the data to be handled has different formats or different data definitions, the data management system performs data definition (schema definition) for the format or data definition type, and creates and manages the table. To do. For example, the conventional sales management system 510 shown in FIG. 77 includes product data, inventory data, customer data, store data, sales data, billing data, etc. as various data of different formats or data definitions necessary for sales management. handle. Therefore, when a relational database (RDB) is used, the conventional sales management system 510 includes a product table 511, an inventory management table 512, a customer table 513, a store table 514, as separate storage areas corresponding to various data, respectively. A sales management table 515, a billing management table 516, etc. are prepared to store and manage corresponding data. That is, in this case, a data definition (schema definition) is created separately for each of the tables 511 to 516 and the like. In addition, when a conventional data management system displays or outputs data on the monitor screen 1, it is necessary to prepare a display (output) program for each different format or data definition. For example, in the case of the sales management system of FIG. 77, each data of different formats or data definitions stored in the product table 511, inventory management table 512, customer table 513, store table 514, sales management table 515, billing management table 516, etc. Correspondingly, a product details display (output) program (PG) 517, a stock details display (output) program (PG) 518, a customer details display (output) program (PG) 519, a store details display (output) program ( PG) 520, sales details display (output) program (PG) 521, billing details display (output) program (PG) 522, etc. are prepared, and data of different formats or definitions is monitored using the different display programs. Each must be displayed on screen 1.

As described above, in the conventional data management system, it is necessary to prepare a separate storage area and display program for each data having different data definitions, and the more tables used by the system, the more the system uses. The database becomes large and requires a lot of effort for program development. Therefore, as a result of intensive studies, the present inventors have invented a data management system as an invention that solves such a problem. The data management system according to the present invention can be embodied in a sales management system 10 according to the first embodiment, for example, as shown in FIG. Specifically, the sales management system 10 according to the first embodiment can handle all data (different formats or data definition data) handled by the conventional sales management system, while the data format or the like as in the past. Rather than creating a separate table by creating a separate data definition (schema definition) for each definition, a column management table that stores and manages definition information for each data (a master table that manages data items or columns) 11 is prepared as a master table so as to correspond to all different data formats or data definitions. The sales management system 10 includes a row management table (transaction table for managing index data) 12 for sequentially storing item values (index data) that serve as identifiers and search keys among data item values included in each data, and A value management table (sequentially stored so that all item values included in each data can be uniquely identified by combining the value of the definition information of the column management table 11 and the value of the identifier of the row management table 12) Transaction system table) 13 for storing item values. Further, the sales management system 10 extracts necessary item values from the data item values stored in the value management table 13 using the identifier stored in the row management table 12 based on the definition information in the column management table 11. A display (output) program (PG) 14 for displaying on the monitor screen 1 in a predetermined format is provided. As a result, the sales management system 10 can store and manage a variety of data definition data only by preparing three tables, the column management table 11, the row management table 12, and the value management table 13. There is no need to prepare a separate table for each data definition. Further, the sales management system 10 can display arbitrary values of various data definition data on the monitor screen 1 in a predetermined format by a single display (output) program 14, corresponding to each data definition. There is no need to prepare a separate program. That is, in the sales management system 10, as shown in FIG. 1, while using a single display program 14, on the display of the monitor screen 1, various tables (store tables) having unique data definitions in FIG. The same data (store data, sales management data, etc.) is displayed with the contents corresponding to the sales management table.

Data separation storage schema (data items)
The data management system according to the first embodiment will be described in general so that it can be applied to a data management system other than the sales management system. As shown in the center of FIG. ) “Column ID” uniquely assigned to each data item (field), “table name” indicating the table to which the data item to which the column ID is assigned belongs, and attribute name (data item) of the data item of each table A schema (data definition) including “attribute name” indicating (name). That is, the column management table includes at least “column ID”, “table name”, and “attribute name” as its own data items. For example, the data handled (data to be managed) is A, B, B, and Ding, and the schema of A is composed of attribute X (ID), attribute A, attribute B, and attribute C, and the schema of B data is , Attribute X (ID), attribute C, attribute B, and attribute D, and the jar data schema consists of attribute Y (ID), attribute A, attribute C, and attribute E. ID), attribute F, attribute G, and attribute H, in the conventional system, as shown on the left side in FIG. Is done. Each table stores an item value (such as x1) for each data item (such as attribute X). On the other hand, in the data management system according to the first embodiment, the column management table 11 has a table name in the case where each piece of data (A, B, B, Ding) having different data definitions (schema) is managed. And attribute names (data item names) are associated with each other and stored in advance in each row, and a column ID is uniquely assigned to each row. Specifically, the column management table stores the table name (class A) and the attribute names (attribute X, attribute A, attribute B, attribute C) to which each column belongs in association with each row. Are associated with unique column IDs (1 to 1) (the same applies to the second data, bag data, and ding data). Thereby, by referring to the column ID of the column management table, the data item (attribute name) of each data (the former, the second, the second, and the second) can be uniquely identified. As described above, the column management table is a master table that stores data items as data item values (not data items) so that all data items to be managed and data items of records can be uniquely specified. .

  In the data management system, the row management table includes a “row ID” that is automatically given every time each record (each row of the table) of the management target data (the former, the second, the second, and the second) is read. It has a schema (data definition) consisting of an “identifier” that uniquely indicates each read record. Each time the data management system reads a record to be managed, it issues a row ID to each read record and extracts a specific data item value in the read record as an identifier. Store in association. For example, the row management table includes the data item values (x1, x2, x3, x4, x5, x6) in the column of attribute X, and the data in the column of attribute Y as identifiers for the tables A, B, B, and Ding. The item value (y1, y2, y3, y4, y5, y6) and the data item value (z1, z2, z3, z4, z5, z6) in the column of attribute Z are stored. Specifically, the data management system sequentially reads the item values (x1, x2, x3, x4, x5, x6) of the attribute X, which is also the ID of each record, every time the records of each row are read. In addition to storing in the identifier column, the row ID is automatically numbered and stored in association with the identifier of each read record (the same applies to the second data, bag data, and ding data). Thereby, each read record (and its identifier) can be uniquely specified by referring to the row ID of the row management table. As described above, the row management table is a transaction system table that assigns and stores unique row IDs to these records so that the read records of all data to be managed can be uniquely specified.

Data separation storage schema (data item value)
Furthermore, in the data management system, the value management table includes a “row ID” that is automatically given every time each record (each row of the table) of the management target data (the former, the second, the second, and the second) is read. Schema (data definition) consisting of “column ID” uniquely indicating each data item of each read record and “value (data item value)” of each data item of the read record uniquely specified by the row ID and column ID Have As described above, each time the data management system reads a record to be managed, the data management system issues a row ID to each read record and stores it in the row management table, and stores each read record in its data item. Each data item value is acquired by decomposing every time. At this time, the data management system determines the table name to which each read record belongs, refers to the column management table, identifies the attribute name that is the data item of the table name, and extracts each data item of the extracted read record A column ID of each attribute name is assigned to the value. Of course, the same row ID is assigned to the same read record. Specifically, the data management system divides the read record into data item units (units of X, A, B, and C) and reads each data item value ( x1, a1, b1, c1, x2, a2, b2, c2,. At the same time, the data management system assigns the row ID (1, 2,...) Assigned to the read record and the attribute names (attribute X, attribute A, attribute B, attribute C) of the read record. Store in association with each acquired data item value. For example, for the record in the first row of the former data, each data item value (x1, a1, b1, c1) is acquired, and for each data item value, the row ID (1) of the record and each data A column ID (1, 2, 3, 4) corresponding to the attribute name of the item value is assigned and stored. Thereafter, the data item values are stored in the value management table for the records in each row of the data A by the same processing. The same applies to Otsu data, Sakai data, and Ding data. Thereby, each data item value of each read record can be uniquely specified by referring to the row ID and column ID of the value management table. As described above, the value management table is a transaction system table that assigns and stores row IDs and column IDs to the data item values so that each data item value of the read records of all data to be managed can be uniquely specified. is there.

  Here, as the identifier of the row management table 13, an item value other than the item values (x1, x2,...) Serving as an index of the management target data (former data etc.) itself or a combination of a plurality of item values is used privately. May be. The column ID of the column management table 11 and the row ID of the row management table 12 are simply numbers (serial numbers) for the sake of simplicity of explanation. Column IDs and row IDs can be created according to the rules (for example, see the description of the column management table described later).

Sales Management System Using Data Separation Storage FIG. 3 is an explanatory diagram schematically showing a data structure when the data management system according to Embodiment 1 of the present invention is embodied in a sales management system. The sales management system 10 according to the first embodiment has the same data structure as that described with reference to FIG. 2, and stores management target data in three tables by the same data processing. In other words, the sales management system stores in the column management table 11 beforehand attribute names (that is, product, inventory management, customer, sales management, store, billing management to be read) as schema definition information of each management target data. The data item name of the table) is stored as master data together with the table name and the unique column ID. Specifically, when the data shown in FIG. 1 is a management target, the column management table 11 includes data items (product ID, product name, price, content) in the product table, and data items (product ID in the inventory management table). , Product name, quantity in stock, location), customer table data items (customer ID, customer name, contact information, person in charge), sales management table data items (product ID, customer ID, number of sales, sales), store The table data items (customer ID, store ID, store name, location) and billing management table data items (billing ID, customer ID, billing amount, closing date) are represented by unique column IDs (1, 2, 3, 4,. ..) are stored in association with each other. In FIG. 3, the sales management table and the store table are not shown for convenience of explanation. In addition, in each table in FIG. 3, the same alphabetic character (alphabet) in parentheses to the right of the attribute name means that the data item is the same. (For example, the product ID (X) in the product table and the product ID (X) in the inventory table are the same data item, and the product name (A) in the product table and the product name (A) in the inventory table are the same data item. Thus, by referring to the column management table 11, in addition to the table name of the management target data, the data item of the table can be determined. For example, for the product table, “product ID, product name, price, content” is defined as the attribute name corresponding to the column ID “1-4”, so the column ID “1-4”. , It can be determined that the management target data table is a “product table”, and that the data items of the product table are “product ID, product name, price, content”. .

  Each time the sales management system reads each record of the management target data, it assigns a unique row ID to the row management table 12 and stores it, and stores a specific data item value of the read record as an identifier. For example, when reading a record of a product table, a row ID (1, 2. A specific item value of the record is stored as an identifier. For example, regarding the product table, product IDs (4901, 49002...) Can be stored in the row management table 12 as identifiers. Similarly, for other tables such as the inventory table, a unique row ID is assigned to each read record, and a specific item value of each read record is acquired as an identifier and stored in association with the row ID. Is done.

  Furthermore, every time each record of the management target data is read, the sales management system divides each read record for each item value of the data item, assigns the same row ID to all the divided data item values, and divides the record. Column IDs corresponding to data item values are assigned in order, and stored as a set of row ID, column ID, and value. For example, when reading a record (“490011, gum, 100, 10”, “49002, bag, 100,10”...) Of the product table, the sales management system first records the first row (490011, gum, 100). , 10) are divided, and row ID (1) is assigned to these four data item values, and column IDs (1 to 4) are assigned to these four data item values in order, and the data The set (“1, 1, 49001”, “1, 2, gum”, “1, 3, 100”, “1, 4, 10”) is stored in the value management table 13. For other tables such as an inventory table, a unique row ID is similarly assigned to each read record. For the records in the second and subsequent rows, the combination of row ID, column ID, and value is stored in the value management table 13 in the same manner when each record is read. For other tables such as the inventory table, similarly, each data item value of the read record is stored in association with the row ID and the column ID.

  4 to 8 show a product table, a customer table, a customer unit price table, an inventory management table, and a sales management table as examples of data definitions in the conventional data management system.

  As shown in FIG. 4, in the conventional product table, “product ID”, “product name”, “unit price”, etc. are defined as data items by the database schema at the time of designing the database, and the corresponding values are used as the data item values. (4901, cigarette, 200 yen, etc.) are stored. Similarly, the customer table defines “company code”, “company name”, “telephone number”, etc. as data items by the database schema at the time of database design, and the corresponding values (A, Yamada Shoji) as the data item values. , 058-111-1111 etc.). Similarly, the customer unit price table defines “product ID”, “company code”, “unit price” and the like as data items by the database schema at the time of designing the database, and the corresponding values (4901, a, 200 yen). Similarly, in the inventory management table, “product ID”, “quantity”, “location” and the like are defined as data items by the database schema at the time of designing the database, and corresponding values (4901, 500, warehouse, etc.) are defined as the data item values. A etc.) are stored. Similarly, in the sales management table, “product ID”, “company code”, “number of sales”, etc. are defined as data items by the database schema at the time of designing the database, and the corresponding values (4901, , 100, etc.).

Column Management Table Applied to Sales Management System FIG. 9 shows a column management table in a case where the conventional data management system of FIGS. 4 to 8 is replaced by the data management system according to the first embodiment of the present invention.
As shown in FIG. 9, the column management table to which the data management system according to the first embodiment is applied is the conventional product table, customer table, customer unit price table, inventory management table, sales management table shown in FIGS. These data definitions are not stored as data items but as data item values, and all the data items of these five tables are defined in advance as data item values and stored as master data. Specifically, the column management table includes “column ID”, “data type”, “table ID”, “branch number”, “serial number”, “data item name” as data items (also referred to as columns or attributes). , “Data type”, “position”, “maximum length”, “minimum length”, and the like are defined. Of these, the data type uniquely indicates the type of data to be managed, and the table ID uniquely indicates the table to which the data to be managed belongs. The data type is an ID that defines a higher-level concept data group than the table ID. For example, when the table ID is “product master”, the product master (master data) is included (that is, other similar data is included). The type of transaction information data can be uniquely indicated. In this case, for example, in the example of FIG. 9, the lower data group such as the table ID “product master data” belongs to the upper data group of the data type “1201”, and the table ID belongs to the upper data group of the data type “1202”. A lower data group such as “customer master data” belongs, and a lower data group such as the table ID “customer unit price master data” belongs to the upper data group of the data type “1203” and belongs to the upper data group of the data type “1204”. The lower data group such as the table ID “stock master data” belongs, and the lower data group such as the table ID “sales master data” belongs to the upper data group of the data type “1205”.

  Here, in the example of FIG. 9, the table ID is represented by a character string such as “product master”, “customer master” or the like for the sake of simplicity of description, but in reality, a predetermined code system (ID assignment rule) It consists of a unique ID (alphanumeric character etc.) given to each table according to For example, the product master data is “10”, the customer master data is “20”, the customer unit price master data is “30”, the inventory master data is “40”, the sales master data is “50”, etc. Can be stored. As described above, the table ID uniquely identifies the data definition (that is, the data item of the table) of each table storing the data to be read. That is, the table ID uniquely indicates the data definition (data format) of the table storing the management target data (read data), and is a code uniquely assigned to the management target data of each data format. In short, the table ID is assigned as a unique code every time the management target data table is different, that is, every data having a different data format. For example, as in the case of the data management system of this example, when reading and storing and managing data to be managed in different data formats such as a product master table, a customer master table, a customer unit price master table, an inventory master table, a sales master table, Corresponding to the plurality of data formats, a unique table ID is assigned and stored in the column management table.

  The branch number is a code for indicating a relationship between tables when there is another table (such as the same hierarchy, lower hierarchy) associated with a table with a certain table ID. For example, the product master table stores and manages product information (various data representing product attributes). In order to manage product information, a plurality of related product information related tables (product information Table groups) are often prepared. In this case, in addition to the “product master table” in the narrow sense, for example, there are one or more tables such as “product ** table” associated with the product master table. Therefore, the branch number is used as information for indicating that there is another table associated with the table indicated by the specific table ID, or information for grouping the tables in such a case. Specifically, when the branch number is “0” (in the case of FIG. 9), it indicates that there is no table related to the corresponding table ID. When the branch number is “1” other than “0”, that is, when there is a table associated with the corresponding table ID, the data to be read is determined by the table ID and branch number (composite key). The data definition of each table to be stored (that is, the data item of the table) is uniquely specified. In this case, the table ID is an ID that uniquely indicates a plurality of associated table groups. Alternatively, the branch number can be used when the record of the management target data has a hierarchical structure. For example, as in the ordering data in the ordering business, a three-layer data structure consisting of “file header record (higher hierarchy)”, “slip header record (middle hierarchy)”, and “slip line record (lower hierarchy)” , The highest value (for example, “1”) is assigned to each data item (each field) of the “file header record” in the highest hierarchy, and “slip header record (middle hierarchy) in the next hierarchy. "In each data item, the middle value (for example," 2 ") indicating that it is lower than the highest value, and the case data item of" slip detail line record (lower hierarchy) "in the next hierarchy Can be assigned and stored with the lowest value (for example, “3”) indicating that it is lower than the middle value, so that the record hierarchy in the data can be identified. In the case of a two-layer structure or a structure of four or more layers, a value can be stored in “hierarchy” in the same manner. However, in addition to the above, an arbitrary value for identifying each layer is assigned and stored. Can do. Further, for all the tables, if there is no other table to be associated and grouped, the branch number data item may be omitted.

  The column ID in FIG. 9 corresponds to the column ID in FIG. 1 to FIG. 3, and uniquely identifies each data item in each table at the end of the combination of the data type, table ID, and branch number. Codes (serial numbers, alphabets, etc.) are assigned in advance. Specifically, in the example of FIG. 9, in the case of the column ID “1201001” assigned to the data item name “product ID” of the table ID “product master table”, the data type “1201”, the table ID “product master”, and The number (01) uniquely indicating the data item is added to the end of the composite of branch number “0” (12010) (resulting in 1201 + 0 + 01 = 11201001). As described above, in the column management table of FIG. 9, for convenience of explanation, the table ID is exemplified as the table name instead of the actual code, and therefore the table ID portion is reflected (added) to the column ID. Not. However, in practice, for example, when the table ID of the product master is “10”, the column ID is 1201 (data type) +10 (table ID) +0 (branch number) +01 (serial number) = 10101001. The serial number indicates the output order and display order of the data items (fields) in the record for each record of the management target data (for example, each record in the product master table). For example, in the case of the product master table, “1”, “1” as the serial number values corresponding to the output order of the item values “product ID”, “product name”, “unit price”,. 2 ”,“ 3 ”... (Continuous value) are stored. Here, in the example of FIG. 9, the number at the end of the column ID and the number of the serial number match, but this does not mean that a serial number value is assigned to the end of the column ID. That is, the number or code at the end of the column ID is uniquely assigned to each data item of the record having the same data format, and does not necessarily match the output order of the data item value of the record. For example, when the data item of the record is added, deleted, or changed, the column ID is also added, deleted, or changed correspondingly, so the number at the end of the column ID in the record is not necessarily This does not indicate the arrangement order of the data items of the record. On the other hand, the serial number completely corresponds to the arrangement order of the data items of the record, and is used to output the data item values in the arrangement order. However, it is naturally possible to specify the item value of each read record by automatically assigning a serial number to the end of the column ID. In this case, management of the column ID itself is easy. However, in order to facilitate the maintenance of subsequent data item addition, deletion, change, etc., a code that is unrelated to the serial number is added at the end of the column ID to uniquely identify the item value of each read record. Is preferably given. Next, “data item name” is the name of the data item associated with each column ID, “data type” is the data type of the data item, and “position” is the position of the data item from the beginning of the record (what Indicates the byte). “Maximum length” and “minimum length” store the maximum number of bytes and the minimum number of bytes of the data item.

  As described above, the column management table in FIG. 9 stores the item names (“product ID”, “product name”...) Of the data items (columns) in each table in FIGS. Store as a data item value, not as a data item. In addition, the column management table corresponds to each value (data item name) of the data item of each table, the value of the data type (“1201”, “1201”...), The value of the table ID (“product master”). ...), Branch number values, serial number values (“1”, “2”...), Column ID values (“1201001”, “1201002”...), And the like. That is, in this example, the data items of all the management target tables are defined and stored as data item values in one column management table. As a result, it is possible to analyze, refer to, determine, etc., the data format (data definition or schema of all tables) of all management target data using a single column management table.

FIG. 10 shows a state in which the conventional table storage data of FIGS. 4 to 8 is read into the row management table of the data management system according to the first embodiment of the present invention, and predetermined data is stored in the row management table.
As shown in FIG. 10, in the sales management system to which the data management system according to the first embodiment is applied, the sales management system has the conventional product table, customer table, customer unit price table, and inventory management table shown in FIGS. Each time each stored data of the sales management table is read from each table, a unique index (row ID) is assigned to the read record, and an identifier is obtained from the read record, Store in the management table. Specifically, the row management table defines “row ID”, “data type”, “table ID”, “identifier name”, “identifier value”, and the like as data items (columns or attributes). Among these, the row ID is a unique (unique) ID that is automatically generated for each read record (one record) of the management target data as described above, and is composed of an arbitrary code (alphanumeric characters, etc.). Can do. In the example of FIG. 10, the combination of alphanumeric characters “SYS001”, “SYS002”,... Is used as the “row ID” value, but the row ID value uniquely identifies each read record. For example, it may be composed of an arbitrary code such as data reading date / time (year / month / day / hour / minute / second). Further, “data type” and “table ID” in the row management table of FIG. 10 correspond to “data type” and “table ID” of the column management table of FIG. That is, the row management table stores data type values (defined by the column management table) and table ID values specific to the read record in association with each row ID. Furthermore, the identifier name of the row management table is the name of the identifier (product ID or the like) acquired from the read record, and the identifier value is the value of the identifier. For example, when reading product master data, the row management table uses the product ID in each read record as an identifier, that is, a unique product ID (“4901”, “4902”, etc.) stored in each row of the product table. Is stored. The product ID is associated with the row ID in a one-to-one relationship. Therefore, by referring to the row management table, it is possible to easily specify which row ID each read record (stored record) having a specific identifier has. When the index of the read record is composed of a composite key (for example, composed of a product ID + company code as in the customer unit price table), the identifier stored in the row management table is also an identifier composed of the composite key.

  Here, in the example of FIG. 10, the row management table stores “index name” (product ID “4901” of the product master data) that is also the identifier of the record itself among the data items of the read record. . However, the row management table only needs to store at least a row ID uniquely assigned to each read record. That is, the row management table may be configured not to store the identifier. On the other hand, the row management table stores representative (basic) items (basic item values) other than the item values used as identifiers among the data item values (field values) of the read record. Good (for example, product name, unit price, etc. in the product master table). In this way, these basic item values can be extracted from the row management table and output quickly as output information, which can be utilized for data output. That is, in this case, the row management table stores one or more basic item values of the read record in addition to the identifier, extracts a desired basic item value using a row ID, an identifier, and the like as a search key, and a desired format ( The data can be utilized by outputting (printing, screen display), etc. in (display format). In this case, in the column management table, by specifying any one or more of the data items of each management target data stored as the item value as a “basic item value” by a flag or the like, the basic specified at the time of reading the record of each data Item values can be automatically extracted. For example, in the column management table, “basic item value specification order” that specifies the order as the basic item value is defined as the data item, and used as the basic item value among the data items of the management target data stored in the column management table A serial number (“1”, “2”...) As a value of “basic item value designation order” is assigned to the desired item.

FIG. 11 shows a state in which all the values are stored by reading the conventional table storage data of FIGS. 4 to 8 into the value management table of the first specific example of the data management system according to the first embodiment of the present invention. .
As shown in FIG. 11, the sales management system to which the data management system according to the first embodiment is applied adopts, for example, the configuration of FIG. 11 as a value management table. According to the value management table of the first specific example, the sales management system stores each storage data of the conventional product table, customer table, customer unit price table, inventory management table, and sales management table shown in FIGS. Each time one record is read from each table (specifically, every time one field of one record is read), the row ID and the column ID are assigned to the read record, and the read data item value is These are stored in the row management table in association with the row ID and column ID. Specifically, the value management table in FIG. 11 defines “row ID”, “data type”, “table ID”, “column ID”, “value”, and the like as data items (columns or attributes). . The “row ID” corresponds to the “row ID” of the row management table, and the “data type”, “table ID”, and “column ID” are the “data type”, “table ID”, and “column ID” of the column management table. Corresponds to “column ID”. As described above, as each record of the management target data is read, a unique row ID is issued and assigned to the record and sequentially stored in the row management table. A row ID (SYS001, SYS002...) Of the read record is stored corresponding to the field value (all item values). Of course, for the same read record, the same row ID is assigned to all field values (item values).

  In addition, when reading each record of managed data, the column management table is referenced, and the field value (item value) of the read record is determined according to the data format of the read record defined in the column management table (data definition of the managed data). ) Are associated with the defined data items of the management target data on a one-to-one basis, and are sequentially stored as values in the value management table. Then, a corresponding column ID value is assigned to the storage record (item value or field value stored in each row) and stored. For example, when a record of product master data is read, the product master part of the column management table is referenced, and the field value of the read record is based on the column ID (“1201001”, “1201002”, “1201003”...) Of the part. (“4901”, “cigarette”, “200 yen”...) Are associated with the data items (“product ID”, “product name”, “unit price”...) Defined in the column management table and divided. And stored as the value of each row in the row management table. Thus, in the value management table according to the first specific example of FIG. 11, one value (field value) is stored in one row. On the other hand, as described above, when a serial number is automatically added to the end of the column ID to uniquely identify the item value of the read record, the read record corresponding portion of the column management table is referred to, In the order of the last serial number (“1”, “2”, “3”...) Of the column ID (specifically, data type constituting the column ID + table ID + branch number + serial number) The field value of the read record is divided in association with the data item defined in the column management table and stored as the value of each row. Thus, in the value management table according to the first specific example of FIG. 11, one value (field value) is stored in one row. In addition, this first specific example shows the field value (data item value) of the read record corresponding to the cell (one value cell) uniquely determined by the row ID of the row management table and the column ID of the column management table. ) Can also be understood as storing. In addition, when each record of the management target data is read, the column management table is referred to, and in addition to the column ID, the data type and the table ID are stored in association with each other. You can also

FIG. 12 shows a state in which all the values are stored by reading the conventional table storage data of FIGS. 4 to 8 into the value management table of the second specific example of the data management system according to the first embodiment of the present invention. .
As shown in FIG. 12, the sales management system to which the data management system according to the first embodiment is applied adopts the configuration shown in FIG. 11, for example, as a value management table. According to the value management table of the first specific example, the sales management system stores each storage data of the conventional product table, customer table, customer unit price table, inventory management table, and sales management table shown in FIGS. Each time one record is read from each table (specifically, every time one record consisting of all fields is read), the row ID, the data type, and the table ID are assigned to the read record. All data item values (field values) of a record are stored in one line. Specifically, the value management table in FIG. 12 defines “row ID”, “data type”, “table ID”, “column ID”, “value”, and the like as data items (columns or attributes). . The “row ID” corresponds to the “row ID” of the row management table, and the “data type”, “table ID”, and “column ID” are the “data type”, “table ID”, and “column ID” of the column management table. Corresponds to “column ID”. As described above, each time the record of the management target data is read, a unique row ID is issued and assigned to the record and sequentially stored in the row management table. At the same time, for each read record, The row IDs (SYS001, SYS002...) Of the read record are stored correspondingly.

  In addition, when reading each record of managed data, the column management table is referenced, and the field value (item value) of the read record is determined according to the data format of the read record defined in the column management table (data definition of the managed data). ) Are associated with the defined data items of the management target data on a one-to-one basis, and are sequentially stored as values in the value management table. Then, the corresponding data type and table ID value are assigned to all the item values or field values of the storage record and stored. For example, when a record of product master data is read, the product master part of the column management table is referred to, and all field values of the read record (“1201”) and all the field values ( “4901”, “cigarette”, “200 yen”...) Are stored in series in the values of the row management table. At this time, as in the case of the value management table of the first specific example, the field value of the read record is divided by referring to the column ID of the column management table, and each value of one row of the value management table is stored. Each can be stored in a section (divided area). At this time, with reference to the column ID, the field values (“4901”, “cigarette”, “200 yen”,...) Of the read record are the data items defined in the column management table (“product ID”, “ Stored in association with “Product Name”, “Unit Price”. Thus, in the value management table according to the second specific example of FIG. 12, one record (all field values) is stored in one line. The second specific example is a read record corresponding to one cell (each cell of “value”) uniquely determined by the row ID of the row management table, the data type of the column management table, and the table ID. It can also be understood that all field values (all data item values) are stored. That is, the data format of each read record (specifically, all data items of each read record) can be specified by the data type and table ID, and the data format of each read record can be specified by the data type and table ID. It can be used as an ID (composite key). In the value management table of the second specific example, all field values are stored in one row, so that the “serial number” in the column table is not necessary as a data item. In addition, since the column ID of the value management table is not associated with each row in the read record unit, “NULL” is automatically stored as a value.

Embodiment 2
FIG. 13 is a block diagram schematically showing the configuration of an ordering management system as a data management system according to Embodiment 2 of the present invention. FIG. 14 is an explanatory diagram schematically showing a data structure when the data management system according to the second embodiment of the present invention is embodied in an order placement management system.

  The data management system according to the second embodiment is obtained by embodying the data management system according to the first embodiment as an order management system 20. The order management system 20 includes a column management table 21 corresponding to the column management table 11, a row management table 22 corresponding to the row management table 12, and a value management table 23 corresponding to the value management table 13. . The ordering management system 20 stores, for each ordering company, a table management table for each ordering company that stores, as master data, the data format of transmission data (transmission record) such as ordering data, receipt data, and payment data transmitted by the ordering company. (Not shown in FIG. 13), and a data exchange management table (not shown in FIG. 13) that stores link information for converting the transmission data of each ordering company into data in the standard data format or the data format of the ordering company. The ordering / ordering management system 20 may further include transmission data of an ordering company, for example, ordering data of a plurality of companies having different data formats (in FIG. 13, the company A ordering data 31 and the company B ordering data 32 are illustrated). Once imported, the data definition of the corresponding company in the column management table 21 (data Referring to formatting), stores the row management table 22 the identifier for each read record of the order data with the line ID, and stores the value management table 23 all item values of the read records with row ID and column ID. That is, the ordering management system 20 receives the order data (Company order data 31 and Company order data 32) of the company according to the data format of each record of the order data of the company defined in the column management table 21. Format (divide, reorder, etc.). Each time the order management system 20 reads one record of the order data 31 to 32, it issues a row ID to the read record, and also includes index data (for example, slip No. or slip detail row) included in the read record. No.) is stored in the row management table as an identifier. At this time, as described above, the order placement / order management system 20 may store other basic item values (for example, product name, order quantity, etc.) of the read record in the row management table 22. Further, every time one record of the order data 31 to 32 is read, the order management system 20 reads all the data item values of the read record according to the data format of the read record defined in the column management table. And a row ID and a column ID are assigned to the read record. At this time, as described above, when one item value of each read record is stored in one row of the value management table 23, a unique column ID is assigned to each row. On the other hand, when all the item values of each read record are stored in one row of the value management table 23, a unique column ID is not assigned to each row, and code information (data type + table ID) that can specify the data format of the read record. Etc.).

  On the other hand, when the ordering / order management system 20 takes in, for example, delivery schedule data of a plurality of companies with different data formats (in FIG. 13, the delivery schedule data 33 and the delivery schedule data 34 are illustrated as examples) in FIG. Similarly to the case of the order data, the column management table 21 refers to the data definition (data format) of the corresponding company, stores the identifier of each read record together with the row ID in the row management table 22, and the value management table 23. All the item values of the read record are stored together with the row ID and the column ID. Here, the order management system 20 includes a single display (output) program (PG) for displaying or outputting the item values stored in the row management table 22 or the value management table 23 in a desired plurality of display formats. ing. The order management system 20 refers to the definition information in the column management table 21 according to the user's request, and uses the identifier stored in the row management table 22 as a key to store the basic item values ( Slip ID, packing ID, etc.) are extracted and output in a predetermined format (displayed on the monitor screen 1). The order management system 20 refers to the definition information in the column management table 21 according to the user's request, and the required item values of the data item values (such as slip details and packing details) stored in the value management table 23. Are output in a predetermined format (displayed on the monitor screen 1).

  Here, the specific table structure of the ordering / ordering management system 20 will be described. As shown in FIG. 14, the ordering / ordering management system 20 is the same as that in the first embodiment described with reference to FIGS. By data processing, each data item (data definition) of the transmission data is stored as a data item value in the column management table 21 in accordance with the data format of the transmission data (order data etc.). Further, the order management system 20 stores, as transaction data, a row ID, an identifier, and the like in the row management table 22, and stores all data item values such as a slip detail ID, a product ID, and a product name in the value management table 23. Storing. Then, the order management system 20 refers to the definition information in the column management table 21 by the display (output) program 26 and outputs the basic item values (slip No., etc.) stored in the row management table 22 in a predetermined format. Or a necessary item value (product ID, product name, etc.) among all data item values stored in the value management table 23 is output. That is, at this time, the order management system 20 uses the display (output) program 26 to store predetermined item values in a predetermined format in the order list table 35 and the order detail table 36 shown in FIG. In the case of delivery schedule data, predetermined items are displayed in a predetermined format on the delivery schedule table 37, the packing details table 38, etc. shown in FIG. In addition, the ordering management system 20 can also display various tables by the display (output) program 26. For example, the slip list table (not shown) uses only basic item values (slip No. order date, etc.) stored in the row management table 22 to quickly display the slip list. In addition, the slip detail display table (not shown) selects and executes any row of the slip list table, thereby extracting various item values of the slip detail row corresponding to the slip ID of the row from the value management table 23, Displays the details of the slip item with the slip number in the row. Here, as a key for extracting a data item value from the row management table 22, a row ID can be used in addition to the identifier.

  Specifically, as shown in FIG. 14, in the order management system 20, when the data shown in FIG. 14 is a management target, the column management table 21 includes data items (slip ID, GTIN, merchandise) Name, quantity), data item of the company order data (slip ID, GTIN, quantity, delivery date), data item of the company order data (slip ID, product ID, quantity, unit price), data item of the company order data ( The slip ID, product name, product ID, and number) are stored in association with unique column IDs (1, 2, 3, 4,...). In addition, in each table of FIG. 14, the same alphabetic character (alphabet) in parentheses to the right of the attribute name means that the data item is the same. Thereby, by referring to the column management table 21, in addition to the table name of the management target data, the data item of the table can be determined. For example, for the company order data, “slip ID, GTIN, product name, number” is defined as the attribute name corresponding to the column ID “1-4”. ”, It can be determined that the management target data table is“ Kosha ordering data ”, and the data item of Kosha ordering data is“ slip ID, GTIN, product name, quantity ” can do.

  Further, every time each record of the management target data is read, the order management system 20 assigns and stores a unique row ID to the row management table 22 and stores a specific data item value of the read record as an identifier. . For example, when a record of a company ordering data (file header record, slip header record, slip detail line record) is read, the row management table 22 stores a row ID ( 1, 2,...) Is issued, and a specific item value of the read record is stored as an identifier corresponding to the row ID. For example, for the product table, the slip ID (Exhibit A1, Exhibit 2 ...) can be stored in the row management table 22 as an identifier. For other data, similarly, a unique row ID is assigned to each read record, and a specific item value of each read record is acquired as an identifier and stored in association with the row ID.

  Further, each time the record of the management target data is read, the order management system 20 divides each read record for each item value of the data item, assigns the same row ID to all the divided data item values, Column IDs corresponding to the divided data item values are assigned in order, and stored as a set of row ID, column ID, and value. For example, when reading the record of the company A order data (“Exhibit 1, 49,001, Gum, 100”, “Exhibit 2, 49,002, Samurai, 20”...), The order management system 20 first records the first line. (Exhibit A1, 49901, Gum, 100) The data item values are divided, row ID (1) is assigned to these four data item values, and column IDs (1 to 4) are assigned to these four data item values. Are stored in the value management table 23 in order, and these data sets ("" 1,1,1 "," 1,2,49001 "," 1,3, gum "," 1,4,100 ") are stored. Similarly, for other data, a unique row ID is assigned to each read record, and for the records after the second row, the row ID, the column ID, and the value of each record are similarly read. Set is value management table 2 It is stored in. In addition, for the other data, similarly, each data item value of the read record is stored in association with the row ID and column ID.

  FIG. 15 is an explanatory diagram showing a data structure of order data exchanged in the data management system according to the second embodiment of the present invention. FIG. 16 is an explanatory diagram showing an outline of a column management table used in the data management system according to the second embodiment of the present invention. FIG. 17 is an explanatory diagram showing a correspondence relationship between the record of the order data and the attribute of each data item of the order data defined in the column management table by the data management system according to the second embodiment of the present invention.

  As shown in FIG. 15, the record of input data is basically composed of three layers of a file header, a slip header, and a slip description, or two layers of a file header and a slip header. Since this hierarchical structure association is indicated by a record sequence in the input data, this data management system creates a row record (record for each line in the line management table) for each slip header in this data management system. This is ensured by defining the hierarchy and parent-child relationship of each record in the column management table described later.

  Further, as shown in FIG. 15, the data management system reads input data in order while separating the input data into record units (file header record, slip header record, slip detail record), and records identifiers in the read records. This is determined by referring to control information of a table management table to be described later, and a record of the row management table is newly created for each read record. When the read record is a slip header record, a new record of the row management table may be created (key ROW_ID is incremented) and used as a basic record for storing one piece of logical slip data. In this case, one record of the row management table is created for each logical slip. Note that the structure of the input data is not a simple structure of 1 record = 1 slip, but may be 1 record = multiple slips, multiple records = 1 slip.

  If it demonstrates with reference to another example of a column management table, as shown in FIG. 16, each record which comprises various data will be produced in the original format which the company defined. In this data management system, the contents of the unique format that differs for each company are defined in units of data items such as column ID, table ID, serial number (sequence number), item name, data type, length, etc. Are stored in the database. In FIG. 16, the table ID is a number that uniquely indicates a company-specific data format of 10 digits or the like (that is, the data definition of the table to be managed). For example, the table ID = company ID (6 digits) + data type (2 digits) + arbitrary number (2 digits). As the arbitrary number, the “branch number” or the like can be used. The column ID is a number that uniquely indicates each data item in one record having, for example, a 12-digit company-specific data format. For example, column ID = table ID (10 digits) + arbitrary No (2 digits). In this case, as an arbitrary number, a number or alphabet uniquely assigned to each data item can be used. In this data management system, various data sent and received between an ordering company with electronic commerce and an ordering company are first read in the order of records divided into records, and the data format for each company is referred to by referring to the table management table. The record matching the data format of the specific company is decomposed for each data item with reference to the column management table, the value is obtained, and stored in the row management table or the value management table. In this way, the data management system defines the unique data format used by each ordering company in the column management table, but also the contents of the unique data format that is different for each ordering company (required by the ordering company) is also column management. Define in the table. Furthermore, the data management system defines the contents of a standard format unique to the data management system (or a standard format proposed by ebEXML etc.) in the column management table. In this data management system, as described above, three types of data formats, that is, picture-specific company-specific data profiles (ordering company data profile, ordering company data profile, standard data profile) are defined in the column management table. Yes.

  As shown in FIG. 17, this data management system targets transmission / reception data with an ordering company, determines points for storing each record of the data, stores them in a value management table, and stores some item values. Is also stored in the row management table, but in reality, it is divided into data item values (field values) constituting the data of one record as shown in the data items constituting the record of FIG. According to this method, it is possible to store important data efficiently and to obtain it accurately. Re-conversion of data using company-specific data profiles and quick slip-by-slip data at the time of failure It can handle extraction, and can also deal with electronic book storage methods.

  FIG. 18 is a block diagram showing a data flow in a data storage procedure for taking order data from the outside into the data management system according to the second embodiment of the present invention and storing the order data in the row management table and the value management table. .

  As shown in FIG. 18, the data storage means 40 in this data management system analyzes the input data (sequential access file) received from the ordering company in order to store the received data in the database, and each data item value of each record. Are extracted and stored in the value management table 23 of the relational database (some are also stored in the row management table 22). That is, first, as shown in FIG. 16, the data format of all records to be managed is defined in the column management table 21. Each record is a collection of a plurality of fields (data items), the record is uniquely identified by a table ID, and each field constituting the record is a column ID or a serial number (sequence No.) in units of table IDs. Uniquely identified. Then, the data management system divides the read physical record by referring to the definition of the matching data format (see the column management table in FIG. 16), and stores the field value of each read record. At this time, as described above, in order to improve system performance (mainly processing speed), in addition to storing one field value in one record (each row of the value management table), this data management system uses one field. All field values can be stored together in one format definition unit (table ID unit of the column management table) instead of the unit. That is, in the value management table, the process of storing one field value in one cell uniquely determined by the combination of the column ID and the row ID is uniquely determined by the combination of the table ID and the row ID). Multiple field values can be stored together in a cell. However, since the number of fields that can be physically stored in one record is limited (for example, 30), if the number of fields constituting the definition of the corresponding data format is more than a limited number (31), the record of the table It is necessary to store one more newly. In this case, the data management system uses a cell sequence NO. It is possible to deal with data division by providing.

  In FIG. 18, when receiving (reading) the order data 31, the data management system first refers to the data exchange management table 25, and deals with the order data 31 between the ordering company and the ordering company (receiving). It is determined whether or not (ordering work) is scheduled, and reading of the ordering data 31 is executed only when a transaction is scheduled. Next, as described above, the data management system refers to the table ID related to the order data of the company in the table management table 24 and reads the order data 31 in units of records. The ordering data 31 read into the data storage means 40 of FIG. 18 is a record unit, that is, a file header record (FL20...), A slip header record (DH20...), And a plurality of slip detail line records (DD20). Sugar ..., DD20 chocolate ...). Next, the data management system refers to the column management table 21, divides each read record of the order data 31 into item values according to the data format of the ordering company, and assigns a unique identifier corresponding to each read record identifier or the like. While storing in the row management table 21 together with the row ID, all item values of each read record are stored in the value management table 23 together with the corresponding row ID and column ID (or information for specifying one record such as a table ID). . In the example of FIG. 15, when the read record is a slip header record, a new row management table record is created and used as a basic record for storing one piece of logical slip data. An example of creating records in logical slip units was explained. However, when the data management system uses an index that is automatically generated and assigned every time each record of the management target data is read as the row ID, not all the records in the slip header record as described above. A row ID is automatically generated in units (file header record, each slip header record, each slip detail row record unit), and stored as an index of each row in the row management table. On the other hand, as shown in FIG. 16 and FIG. 17, the column ID is created in accordance with the above rules using a 12-digit number (0123...), And records (file header records, slips) of management target data (ordering data) Each data item (header record, slip detail record, etc.) (for file header records, record classification, file type, data creation date, etc.) For slip header records, record classification, store code, department code, etc. In the case of a record, it is uniquely assigned to a record classification, product name, standard, etc.).

  FIG. 19 is an explanatory diagram schematically showing a procedure for exchanging data between an ordering company data profile and an ordering company data profile via a standard data profile by the data management system according to the second embodiment of the present invention. FIG. 20 shows the standard data corresponding to the item value of the ordering company data from the predetermined column ID of the ordering company data profile representing the predetermined item value of the ordering company data by the data management system according to the second embodiment of the present invention. A procedure for acquiring a predetermined column ID of an order data profile representing an item value of order enterprise data corresponding to an item value of the standard data via a predetermined column ID of the standard data profile representing the item value of It is explanatory drawing shown.

  The data conversion method will be described. As shown in FIG. 19, the data management system performs column management of three types of company-specific data profiles: an ordering company-specific data profile, an order-receiving company-specific data profile, and a standard data profile. It is defined in the table. This company-specific data profile defines the attributes of the data items that are the minimum elements of each of the records that constitute various data exchanged in electronic commerce, and is used for mapping work. . EDI using a standard format is ideal for reducing the cost of format conversion work. Therefore, also in this data management system, the mapping work is performed between the ordering company-specific data profile and the standard data profile, and the mapping work is performed between the standard data profile and the order-receiving company-specific data profile. By doing so, as shown in the data conversion overview of FIG. 19, the ordering company-specific data profile can be obtained via the standard data profile without mapping between the ordering company-specific data profile and the ordering company-specific data profile. The data conversion can be realized by obtaining the related information between the data items between the data profile and the data profile of the order receiving company. FIG. 20 schematically shows the contents of a table (item relation definition table) in which relevant information between data items of the company-specific data profile is actually stored. Here, the column ID is a number that uniquely indicates a data item record of a predetermined digit (for example, 12 digits).

  In the example of FIG. 20, the third data item (column ID = column ID = 111111010) of the file header record (table ID code = 1111112010) constituting the ordering data (data type code = 20) received from the ordering company (company code = 111111). 111111201003) through the fourth data item (column ID = 201004) of the order (data type code = 20) file header record (table ID code = 2010) of the standard (company code = 000000) data profile, Processing of exchanging data with the second data item (column ID = 999999991002) of the file header record (table ID code = 999999992010) of the order receiving data (data type code = 20) of the ordering company (company code = 999999) Flow shows To have. The data conversion function at the right end of the table of FIG. 20 is a conversion function used for data conversion. However, in this data management system, many functions are prepared so as to be compatible with all data conversion. In FIG. 20, the function code “1” indicates data storage, and the value of the data item having the column ID “111111201003” in the read data (order data) of the ordering company (stored value actually stored in the value management table) Is stored in the column ID “201004” of the standard profile, and the value of the data item stored in the column ID “201004” of the standard profile is the column ID in the format (profile or format) specified by the contracting company. The process of obtaining as the value of the data item having “9999999920002” is executed using the function code.

  FIG. 21 is an explanation showing an outline of item value management used for processing when the meaning and method of use of item values differ between companies when data is exchanged by the data management system according to the second embodiment of the present invention. FIG.

  The problem at the time of data conversion and the solution will be described with reference to FIG. When performing data conversion, there are various problems that must be solved. In this data management system, these problems are solved as follows. First, regarding item names (synonyms), various data item names are assigned to the format unique to the ordering company. In this data management system, the values actually assigned to these data items are verified, and even if the data item names are different, the relation definition between the data items determined to have the same data item value is performed. . For example, the association definition is made as an order number⇔slip number, department code⇔classification code. Concerning item contents (synonyms with the same name), in contrast to item names, if it is determined that the actual value is different even if the data item name is the same, a related definition is made between the data items. Not. Furthermore, in this data management system, GTIN (JAN code) is generally used for product codes, and any of common customer code, standard company code, and global location number (Global Location Number) is used for company codes. The principle is to do. However, local product codes and local company codes can also be converted. For example, product code (JAN code) ⇔product code (in-store), company code (common customer code) ⇔company code (in-store), and the like. Next, regarding the difference in attribute (data type), in the present data management system, when a relation definition between data items is defined, the attribute conversion is automatically performed. In principle, text is stored left-justified and numbers are right-justified. For example, numeric value | date, text | numeric value | number, date | text | text. Next, regarding the difference in display method, that is, the display method of the data item, any notation method such as 0 (zero) suppression, display of the decimal point position, substitution of a delimiter character can be used by using an optional function. For example, telephone number: 03 (4321) 1256⇔03-4321-1256. Next, regarding the difference in the number of digits (length), when related information between data items having different lengths is defined, data may be lost when data is converted. This data management system displays a warning message when an actual data item value is lost during data conversion. The user can deal with the problem by changing the length of the data item on the receiving side.

  In addition, since this data management system supports GTIN codes, when a JAN code is used, 0 (zero) is added to the first digit and stored. For example, the JAN code (13 digits) and the GTIN code (14 digits). Next, with respect to domain values (meaning of item values), when a code is assigned to a data item value, the code system is determined for each company. In this data management system, in order to perform semantic conversion of these code systems, the system standard of the contents of various data items is determined and stored as a system standard profile. Through this standard profile, the user can perform code semantic conversion as well as data conversion. For example, the payment method of the company A: 1 = next month, 2 = second month, the payment method of the company B: 0 = next month, 1 = next month, etc. In FIG. 21, the payment method of 999999991002 is a: the following month, b: the following month, c: the following month, 000000201004, a: the following month, i: the following month, c: the following month, and 1111111201003. , 0: Next month, 1: Next month, 2: Next month, 0⇒A⇒a, 1⇒I⇒b, 2⇒C⇒c. That is, in the item value management (COLUMN_VALUE) table of FIG. 21, the second data item (file ID / 9999992010) of the order data (data type code = 20) of the order receiving company (company code = 999999) is shown. Column ID = 9999999910002) represents the payment method of the contracting company, and as data item values, “a” means the next month, “b” means the next month, and “c” means the next month. Further, the third data item (column ID = 111111201003) of the file header record (table ID = 1111112010) constituting the ordering data (data type code = 20) received from the ordering company (company code = 111111) is This represents the payment method of the ordering company. As the value of the data item, “0” means the next month, “1” means the next month, and “2” means the next month. Further, the fourth data item (column ID = 201004) of the order (data type code = 20) file header record (table ID = 2010) of the standard (company code = 000000) data profile is the payment of the standard data profile. As a value of the data item, “A” means the next month, “I” means the next month, and “C” means the next month. In this case, the data management system of the second embodiment refers to the item value management table of FIG. 21 at the time of the data conversion, and sets the data item value “0” of the ordering company profile to the data item of the standard data profile. The value “a” of the ordering company profile is automatically converted to the value “a” of the ordering company profile, and the value “1” of the ordering company profile is changed to the value “I” of the data item of the standard data profile. ”Is automatically converted to the value“ b ”of the data item of the ordering company profile, and the value“ 2 ”of the data item of the ordering company profile is converted to the value“ c ”of the data item of the standard data profile. The data item value “c” of the ordering company profile is automatically converted. In this way, even if the data item value of the data in the format specified by the ordering company has a different meaning and different code system from the data item value of the ordering company, the difference can be absorbed through the standard data profile. .

  FIG. 22 incorporates a new ordering company data profile and link information between the ordering company profile and the standard data profile into the data management system according to the second embodiment of the present invention, and stores data based on the new ordering company data profile. It is a block diagram which shows the data flow in the profile taking-in / display / output procedure in the case of displaying and outputting.

  As shown in FIG. 22, the profile fetch means 50 of the order placement management system 20 according to the second embodiment uses the network NT to create a data profile of a new company sequentially created by a profile management system placed on the network or the like. To the column management table 21, and the column management table 21 is updated. At the same time, the link information between the new company's (original) data profile and the standard data profile is also acquired and stored in the item relation definition table 27 via the network NT, and the item relation definition table 27 is updated. The That is, the order receiving / order management system 20 further includes an item relation definition table 27, stores definition link information between the data profile of the ordering company and the standard data profile, and also includes the standard data profile and the data profile of the ordering company. Definition link information between them is also stored. Based on the definition information and the link information, the item values from the row management table 22 and the value management table 23 are output to the monitor screen 1 and the book table 2 in a predetermined format via the display program 26. The item relation definition table 27 in which the link information 52 is updated and stored corresponds to the item relation definition table of FIG. That is, the trigger column ID of the link information 52 corresponds to the column ID of the company-specific data profile of FIG. 20, the target column ID of the link information 52 corresponds to the column ID of the standard data profile of FIG. The function ID 52 corresponds to the data conversion function code of FIG. Therefore, also in the example of FIG. 22, the order data stored in the value management table 23 according to the column definition of the column management table 21 (data profile unique to the ordering company) is stored in the item relation definition table 27 in the same manner as in FIG. Refer to the link information (link information between each data item of the ordering company data profile, standard data profile, and ordering company data profile), convert it to data in the data format specified by the ordering company, and output it in a form format. The screen 1 can be displayed in a predetermined format.

FIG. 23 is a block diagram showing a data flow in a data output procedure for outputting various data by the data management system according to the second embodiment of the present invention.
In the data output, the data management system reads records stored in the value management table 23 (in some outputs, the row management table 22), and creates output data having designated contents designated in advance. The data management system can specify ordering company slip data 61, industry standard data (system standard data) 62, and order receiving company designation data 63 as instruction contents. Further, data creation in the data management system may be performed by repeating the same process for the number of slips, and outputting the contents together with a designated file name. Here, the details of creation of output data will be described. The data management system creates various designated data from the item values of each record (received from the ordering company) stored in the value management table 23. Further, the data management system reads records stored in the row management table 22 as necessary, and outputs a slip list (by data type, by ordering company, date range, etc.) on the screen. When a single slip is selected, the detailed contents of the slip can be displayed. Also in this case, the data management system can designate the ordering company specific data 61 (default), ordering company slip data, industry standard data (system standard data) 62, and order receiving company designation data 63 as the detailed display contents. . Then, the data management system refers to the column management table 21 based on the designated display content, determines the table ID of the record to be displayed, and sets each item value included in the record specified by the table ID to the item Obtained sequentially from the value management table 23 and displayed as a set. The table ID can also be determined by the table management table 24.

  Here, since only the ordering company original data 61 (default ordering company original data) is stored in the value management table 23, each item value to be displayed when other display contents are selected. 20 is searched for the item relation definition table corresponding to the table of FIG. 20, each value of the corresponding ordering company unique data 61 is obtained, and each value of the item name of the record of the table ID designated for display is set as a set. indicate. On the other hand, when the ordering company unique data 61 (default) is designated, the data management system obtains and designates each value from the value management table 23 according to the item order of the data items included in the record identified by the table ID. The display mode is displayed. That is, the record (corresponding row) of the value management table 23 is determined using the table ID as a search key, and the values stored in the order indicated by the column ID are acquired and displayed in sets in the sequential number display order. . Specifically, when any of ordering company slip data, industry standard data, or order-receiving company designation data is designated, the data management system follows the order of the items included in the record specified by the table ID, The link information with the corresponding item of the ordering company unique data is acquired from the item relation definition table. That is, the data management system searches the record of the item relation definition table using the column ID (trigger column ID) as a key, and stores the data item of the original data (ordering company unique data) corresponding to the display-designated data item. Current column ID (target column ID) is acquired. Specifically, the link information between the data items corresponding to the original data is acquired for all the data items designated for display by the method described with reference to FIG. Then, the data management system replaces all the data items designated for display with the data items of the acquired original data, and acquires the item values of the data items after the replacement from the value management table 23. That is, the data management system uses the table ID (which may be a column ID) as a search key to determine the storage row (cell record) of the value management table 23 for the record of data designated for display, and in the order indicated by the column ID. The stored item values are acquired sequentially and displayed as a set with the item name of the data item designated for display.

Embodiment 3
FIG. 24 is a block diagram schematically showing the configuration of the data management system according to the third embodiment of the present invention together with the profile management system.

  As shown in FIG. 24, the data management system according to the third embodiment includes a data exchange system 110 similar to that of the above-described embodiment and a profile management system 120 as described in the above-described second embodiment. The data exchange system 110 includes a column management table 111 similar to the column management tables 11 and 21, a row management table 112 similar to the row management tables 12 and 22, and a value management similar to the value management tables 13 and 23. A table management table 114 similar to the table management table 24; and an item relation definition table 117 similar to the item relation definition table 27. On the other hand, the profile management system 120 includes the same * company (A company, B company...) Data item definition table 122 corresponding to the column table defining the company-specific data format (company-specific data profile), Similar to the standard data item definition table 121 corresponding to the column management table for defining the standard data format (standard data profile) and the item relation definition table 117, * link information between the company-specific data format and the standard data format And an item relation definition table 123 for defining The data management system according to the third embodiment refers to the table management table 114 and the column management table for the primary data (order data, product data, etc.) of each company's own format received from each company via the network NT. All item values of all records are stored in the value management table 113 together with row IDs and column IDs (or table IDs), and some item values such as identifiers are stored in the row management table 112 together with row IDs. Further, when a new company data profile is added, the profile management system 120 updates the * company data item definition table 122 for the added data profile, and the updated data format and the standard data format. The link information is created using the standard data item definition table 121 and stored in the item relation definition table 123. Then, the data exchange system 110 acquires the updated company-specific data format definition, link information, and the like via the network NT, and updates the column management table 111 and the item relation definition table 117.

Embodiment 4
Next, the development concept of this data management system will be described. The investment in EDI of the ordering companies located in the DIY industry is only increasing. SMEs that are unable to invest in the EDI environment will not give up entering the industry, despite the fact that the number of contracts for products that presuppose electronic commerce increases year by year, despite the development of products that consumers demand. I do not get. Reducing costs associated with the introduction and operation of EDI is an important issue for contracting companies. The development concept of this electronic data conversion system is not to provide solutions that can be individually addressed by each contracting company, but to develop solutions that reduce costs for the industry as a whole. It is. Here, it is assumed that there are 10 ordering (retail) companies and 100 ordering (wholesale and manufacturing) companies in the entire DIY industry, and there is electronic commerce between all the companies. First, if the standard format is used for all EDIs between companies, the ordering company has 10 x 10 format conversion (unique standard) programs, and the contracting company has format conversion (unique standard). Standard) programs are 1 × 100 companies = 100, and there are 110 format conversion programs in the entire industry. Next, when the original format is used for all EDI between companies, the ordering company does not convert the format, so 0 × 10 companies = 0, and the ordering company uses the format conversion (ordering and ordering) program. However, 10 companies × 100 companies = 1,000, and there are 1,000 format conversion programs in the entire industry. Thus, it can be seen that when the standard format is used, the required format conversion program is remarkably smaller than when the original format is used.

  The actual total number of companies and the total number of e-commerce in the industry as a whole is not accurately known, but it has already been explained that the development and operation of format conversion programs represented by mapping work are very costly. By using the standard format, the cost of EDI for the entire industry can be greatly reduced. For example, if the ordering company: order-receiving company = 200: 200, the actual reduction is 99% at 400: 40,000. In addition, the standard format conversion at the ordering company and the standard format conversion at the ordering company, as long as there is a standard format, the ordering company that currently conducts e-commerce has multiple orders with transactions. In view of the fact that the format conversion is performed in response to the company, it can be sufficiently realized. Therefore, for example, the CII standard format is customized according to the current situation, and the above two format conversions are performed. In particular, by performing the format conversion by the data management system (EDITY) as described above, there is no difference in the ordering company from the current situation. On the other hand, it can be seen that in the order receiving company, there is no individual format conversion corresponding to a plurality of ordering companies with transactions, and the EDI environment necessary for electronic commerce is only for data transmission / reception. In this data management system, the ordering company's own mapping definition and format conversion program that all the ordering companies in the industry currently have are not transferred and managed. Create a new industry standard format that can support future XML-EDI, and convert the format through this standard format, so that the entire industry can respond immediately to changes in the original format of the ordering company. From this point of view, it will maintain and manage a lean format conversion system on behalf of all contracting companies.

  FIG. 25 is a data flow diagram showing data to be exchanged in the electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention in accordance with the transaction process. FIG. 26 is a table showing a list and configuration of data to be exchanged in the electronic commerce data exchange system as the data management system according to the fourth embodiment of the present invention. FIG. 27 is a data structure diagram showing a data structure of standard data used in an electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention.

  The management target data of this data management system will be described with reference to FIGS. The main target data managed by this data management system is various data transmitted and received between an ordering company with electronic commerce and an ordering company. Each type of data is a fixed-length text file in which the length of one record is determined, and is composed of a collection of a plurality of records. In general, there are three types of records: a file header / record, a slip header / record, and a slip detail line / record. This is an indication that electronic commerce is still performed in units of slips, and the order (order) information, delivery information, and receipt information are in three layers: file header record, slip header record, slip detail line / record. In many cases, the data is composed of the payment information and the billing information, and the data is composed of two layers of the file header record and the slip header record. Since the relationship of the hierarchical structure of this record is indicated by the record sequence in various data, this data management system records the record while ensuring the hierarchical relationship of the file header / record, slip header / record, slip details / record. Store in the database in units. As shown in FIG. 25, in this data management system, it is assumed that the business flow between an ordering company with electronic commerce and an ordering company is as shown in the above figure, and target data to be exchanged between each trading company is determined. Yes. FIG. 26 shows a list and configuration of data. The record structure of various data is as shown in FIG. The file header record is a record shared as a header for all data. Only the arrival schedule (packing) data has four layers, and the others have three layers.

  Next, each function of the electronic data conversion system (this data management system) is handled from the following three viewpoints, handling of data to be transmitted / received, issues and solutions for data conversion, and data history conforming to the distribution work flow The securing will be described in order. First, regarding the handling of data to be transmitted / received, main target data managed by this data management system is various data transmitted / received between an ordering company with electronic commerce and an ordering company. If this data is analyzed from the viewpoint of how it should be handled, it can be classified into the following five types. The first is data to be captured by the contracting company, such as “product code” and “order quantity”, which is indispensable to the contracting company for operations such as shipping operations. In this data management system, the data received from the ordering company is converted into a format designated by the ordering company and output as a data file so that it can be used in the system of the ordering company. The contracting company must import this file and import various data into the system. Next, the second data is data to be printed on the slip, and indicates the print data of the delivery slip attached when the order receiving company ships the product. This data management system can print unified slips (TA1 type, TA2 type, etc.). In addition, the ordering company often specifies the details of the contents of the delivery slip, the printing position, and the printing method. In this data management system, even if this detailed content is included, the data profile for each ordering company is included in the company-specific data profile. Because it is defined, a delivery slip can be automatically printed when data conversion is performed. Of course, it is also possible to change the order quantity from the ordering company to the scheduled delivery quantity after inventory allocation or the delivery fixed quantity after picking work. Since it is defined in the profile, it is possible to print with a modified image designated for each ordering company. The third is data used only by the ordering company, and indicates data unique to the ordering company that is not used in the first and second. This data is often used in a system unique to the ordering company, and is often specified as a data item returned from the ordering company to the ordering company, and needs to be carried around. Since this data management system stores all the original data received from the ordering company, the data specified in the reply data of the original format specified by the ordering company is extracted from the data received in advance when necessary. To use. The fourth is data for controlling data transmission or data configuration, and refers to control data such as data type, data structure, communication control data, such as “data type”, “file classification”, and “relay center code”. In this data management system, these control data are analyzed, the consistency of data structure and data relation is ensured, and necessary data is stored in a database in the system. These data are not open to the system user in principle, but all the original data received from the ordering company are stored and can be referred to. The fifth item is data equivalent to a plurality of the above categories, and this data management system deals with each of them separately (see above).

  FIG. 28 is a table relation diagram showing a data structure of a database used in an electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention. FIG. 29 is a table showing a table list of databases used in the electronic commerce data exchange system as a data management system according to the fourth embodiment of the present invention.

  A data structure of a database (RDB) used in the data management system will be described. First, the company management (CUSTOMER) table manages information on each company targeted by the data management system, and manages various information on the ordering company and the ordering company. Usually, the person in charge of the data management system inputs information on the ordering company side, and the person in charge on the ordering company side that is the user company inputs information on the ordering company side. In order to ensure the security, the user can be input by registering the person in charge. Next, the data exchange management (EXCHANGE) table manages information related to data exchange between each user company for each data type, and manages various types of information exchanged between companies. Normally, these pieces of information are input by the person in charge at each user company. Next, the data type management (DATA_KIND) table manages data types handled by this data management system, and manages data types from ordering to billing to payment. The data type management table shows a group of tables. Normally, this information is input by a person in charge of the data management system.

  Next, the table management (TABLE) table manages various tables and records for each data type for each company. Information on the ordering company side in the table management table is inputted by the system person in charge, and information on the ordering company side is inputted by the user company person in charge. Here, the table management table may be configured to have a mechanism (record sub ID) for storing and managing the hierarchical relationship between records. For example, the table ID defined in the table management table can be 8 digits of company code + 2 digits of data type + record sub ID. Further, the table management table defines and stores record control information (CONTROL_INI) for specifying each record of the read data and dividing the record by record unit. This record control information is information describing, for example, the position and content in the read record for the item value indicating the record. As an example, the control information may be [MATCH_SP = 0; MATCH_CODE = AAA]. Here, “MATCH_SP = number;” is position information indicating a specific position (starting position of a field to be matched) of a read record (consisting of a plurality of fields), and indicates a byte position from the beginning (0) of the record. . “MATCH_CODE = value;” is information indicating the content (value) of a field at a specific position of the read record, and indicates a character string code to be checked. As described above, the control information can be described by a set of the position and its value, and if necessary, the control information can be described by a plurality of sets. The following extended description is also possible. That is, when a plurality of MATCH_CODEs are designated, for example, [MATCH_SP = 0; MATCH_CODE = {AAA, BBB, CCC};]. In this case, if the code of the field value at the designated position in the read record is any one of “AAA”, “BBB”, and “CCC”, it matches the control information, and the read record can be specified. When negative information is specified for MATCH_CODE, for example, [MATCH_SP = 0; MATCH_CODE = NOT {AAA, BBB, CCC};]. In this case, if the code of the field value at the designated position is other than “AAA”, “BBB”, or “CCC” in the read record, it matches the control information, and the read record can be specified.

  Next, the column management (COLUMN) table manages various data information in each company targeted by this data management system, and constitutes each management target table (management target record) specified by the table management table. Manage the attributes, position, length, etc. of each data item. That is, the column management table defines the data format of each management target data. Normally, information on the ordering company side is input by the person in charge of the data management system, and information on the ordering company side is input by the person in charge of the user company. The item value management (COLUMN_VALUE) table manages the value stored in each data item and the corresponding semantic content when conversion of the value and content is required among the data items defined in the column management table. It is. That is, the item value management table defines the domain value of each company. Normally, the person in charge of the data management system inputs information on the ordering company side, and the person in charge of the user company inputs information on the ordering company side. The row management (ROW) table stores basic management (corresponding to rows in a spreadsheet system) information of records stored in the data management system. The record unit identifier and basic data of the read data are stored in the row management (ROW) table. And the row ID indicating the number of the record of the input data as a key item. That is, the row management table stores a record identifier (IDENTIFIER), record related information, and the like. In addition, the row management table stores up to five values (match values) copied from the data contents (search values) for the search items (used in the matching process between the ordering data and the delivery data). The row management table creates each row for each stored record.

  The value management (CELL) table stores input data in record units, and stores data item values in cells uniquely indicated by the row ID of the row management table and the column ID of the column management table. As described above, the value management table can collectively store the contents of one record. That is, in the value management table, the row ID indicating what number record of the input data and the table ID or column ID which is the key item of the table management table referred to when the record is analyzed are the basic key items. Become. It is an image in which data is stored in a cell at a point where a row and a column of a spreadsheet calculate. Originally, one value should be stored in one cell, but in order to improve performance, this data management system can also store a large number of items in one cell. In this case, assuming that the number of items in one record is greater than or equal to the planned number of items, cell sequence No. A new cell record is created and stored from the value of the item exceeding the planned number of items. The item relation definition (COLUMN_CHAIN) table manages relation definition (link) information between data items defined and managed in the column management table (of different data profiles). That is, the item relation definition table includes a trigger item (trigger column ID, that is, column ID of the data profile of the ordering company or the ordering company in the example of FIG. 20) and a target item (target column ID, ie, FIG. 20). In this example, the column ID of the standard data profile is shown, and a function (function code) and its parameters used when converting values between items are managed. As a general rule, each item of the company-specific data profile is selected and stored in the trigger item that is the trigger column ID of the item-related definition table, and each item of the standard data profile is selected as the target column item that is the target column ID And store. Thereby, data conversion between each item of the ordering company data profile and each item of the order receiving company data profile can be realized via each item of the standard data profile. Usually, the person in charge of this data management system inputs the link information between the items in the ordering company side data profile and each item in the standard data profile. The user company person in charge inputs the link information between the items of the profile. It is also possible to directly link information between the ordering company side data profile and the ordering company side data profile without using the standard data profile.

  Next, the function (FUNCTION) table manages function information used in the system, and manages system functions used in the item relation definition table. This information is input by the person in charge of the data management system. Next, the volume management (VOLUME) table manages the database area when using the data management system. The storage area of the database for storing various data input / output by the data management system is stored in the target company. Manage by year, year, etc. The information is automatically updated by the data management system according to the content specified by the user. Next, the company-specific storage area management (VOLUME_CUSTOMER) table manages an ordering company that is a data conversion target in units of database areas, and manages an ordering company that is a target of data conversion in units of created volumes. The information is automatically updated by the data management system according to the content specified by the user. Next, the system management (SYSTEM) table manages system information when the data management system is operated, and manages a user user system such as a user key. Next, the work management (TRANSACTION) table manages various information of the data management system sound data conversion work for each work (each transaction). Next, the target management (SYSTEM_OBJECT) table defines target objects that are management targets of the data management system, and manages slips, packing, payment details, and the like. This management target is uniquely determined depending on what is the data information defined in the table management table. For example, the target object is “Order” for the file header record that constitutes the order data of a certain company, “Voucher” for the order header record, “Voucher Detail” for the slip detail record, {Order "Corporate code + data transmission date and time", "Invoice" can be acquired by {Ordering company code + Store code + Voucher number}, and "Invoice details" can be acquired by {Ordering company code + Store code + Voucher number + Line number}. An identifier that uniquely identifies the target object can be assigned. Although not shown, all the tables such as the column management table include “valid date / time”, “valid date / time”, “registration date”, “update date”, “deletion date”, “ Data items of “access control” and “registrant information” are provided, and values of the data items are stored. In particular, date and time information such as “valid date (self)” and “valid date (self)” provides information that can limit the validity period of the column management table definition (a period during which the column definition can be used), etc. It can be used for version management of column definitions.

FIG. 30 is an explanatory view schematically showing matching processing when a difference occurs between ordering data and shipping data by the electronic commerce data exchange system as a data management system according to the fourth embodiment of the present invention. is there.
As shown in FIG. 30, an order data slip No. 100 slip line No. For item 2, the order is for 10 products B. However, if out-of-stock has occurred as a result of picking by the ordering company, 8 products B will be shipped. Here, when creating the shipping schedule data, this data management system first uses the item relation definition table to store the ordering data as the ordering company original data (original data) stored in the value management table. Data is converted from the data profile to the standard data profile, and the order data as the system standard data is created. Next, this data management system uses the field relation definition table to convert the order data as the ordering company side system standard data into the ordering company data profile and convert the ordering data as the ordering company specification data. create. Next, the order receiving company uses its own system to reflect the out of stock in the order receiving data in the order receiving company designated data format, and creates shipping schedule data in the order receiving company designated format. Next, this data management system uses the item relation definition table to convert the shipping order data in the order receiving company specification format from the ordering company data profile to the standard data profile, and to ship as system standard data. Create data. Note that an order receiving company that does not have its own system uses this data management system to create shipping schedule data, so this data conversion process is not necessary. At this time, the data management system refers to the column management table and the target management table, and checks the matching item values (slip No., detail row No., etc.) required for data matching between the ordering data and the shipping schedule data. ) Is stored in the row management table. Therefore, here, the data management system obtains the matching item value related to the ordering data (= order receiving data) to be matched from the row management table, and the slip No. Value (slip No. 100) and detail line No. (Detail line Nos. 1 to 5) and the slip No. of shipping schedule data. Value (slip No. 100) and detail line No. The order quantity of the order data is compared with the shipment quantity of the shipping schedule data, and if there is a difference, it is reflected in the shipment quantity (shipping correction). In other words, in this case, the data management system uses the order data slip No. 100 slip line No. 2 and the shipment data slip No. 100 slip line No. Shipment schedule data is created by automatically matching the number of the two products B (matching process). Specifically, the present data management system has a slip line No. For item 2, the number of products B is set (shipment correction) to 8 (which is the actual number of deliveries) instead of the original (which is the number of orders). In this way, the matching item value stored in the row management table can be effectively utilized when the delivery note is corrected. Finally, this data management system uses the field related definition table to convert the shipping schedule data as the system standard data from the standard data profile to the ordering company data profile, Create shipping schedule data (shipped). In this way, the ordering company receives the arrival schedule data of the value that is actually shipped.

  Here, as will be described later, the matching process (matching process) is the column sub ID defined in the column management table (when the corresponding column ID data item is used in the matching process, the matching process defined in the target management table). This is realized by using the object ID of the data item, the matching item value stored in the row management table (the item value of the data item used in the matching process), and the object ID of the target management table. Specifically, the data management system refers to the column sub ID of the column management table when creating the row management table when reading the record, and the specific data item (slip No., etc.) of the read record is matched. Judge whether the item is used in. When the data item is a matching item used in the matching process, the data item is defined in advance in the target management table and stores a corresponding object ID. For example, in the above case, the order data slip NO. The object ID “20201” is stored in the data item of “No. The object ID “202011” is stored in the data item. In addition, when an object ID is stored in the column sub ID column corresponding to the data item, the column management table acquires the data item corresponding to the object ID from the target management table, and the item value of the data item Are stored in the corresponding matching item value column of the row management table. For example, in the above case, the data item “slip No. (slip number)” of the object ID “20201” is acquired from the target management table, stored as the corresponding matching item value in the row management table, and the object ID “201011”. Is acquired from the target management table and stored as a corresponding item value in the row management table. As a result, the data management system, in the above-mentioned matching process, uses the matching item values (slip No. and detail line No.) for each detail of each slip between the order data (order data) to be processed and the shipping schedule data. If there is a difference in the quantity etc. of the matched detail lines (when the shipment quantity is less than the order quantity), the shipping schedule data is corrected to reflect the shipment quantity.

Embodiment 5
FIG. 31 is an explanatory diagram showing the overall configuration of a network system that implements electronic commerce data exchange by applying the data management system according to the fifth embodiment of the present invention.
As shown in the upper part of FIG. 31, data transmission / reception between an ordering company and an order receiving company is based on the premise that an existing communication infrastructure is used. Communication procedures such as JCA, Zenginkyo, and Zengin TCP / IP are used. The lower left of FIG. 31 shows a data management center or a system support center (“eDIY” support center). The data management center manages the standard profile and the company profile, distributes the standard profile and the company profile according to the request of the user who uses this data management system (“eDIY” system), and according to the history situation. Make a charge. The lower right of FIG. 31 shows this data management system (“eDIY” system). This data management system can exchange and translate electronic data with business partners by installing necessary profiles.

  Next, a simple processing flow of the data management system shown in FIG. 31 is briefly shown below. First, in the data management center (“eDIY” support center), a standard profile is defined according to an industry standard message format. Next, in the data management center (“eDIY” support center), the message format of each ordering company belonging to the industry is analyzed and defined as a company profile along with the relationship with the standard profile. Next, when a company using a data management system ("eDIY" system) determines a business partner for electronic commerce and requests it from the data management center ("eDIY" support center), the necessary standard profile and company profile are downloaded. And installed on the system. Next, the data management center defines a message format required for interfacing with an existing system as a user profile. Next, in the user company's system, data conversion and translation between the partner company's unique data and the user company specified data are automatically performed mutually. Here, the import data of various files necessary for the company's existing system is created by inputting various data of the business partners received through the current VAN company into the data management system ("eDIY" system). Also, various data to be transmitted through the current VAN company are created by inputting various files created in the existing system to the data management system (“eDIY” system).

  Next, the mechanism of data conversion and translation will be briefly described. First, the data conversion and translation of the data management system (“eDIY”), as described above, defines item relations between the ordering company-specific data profile and the standard data profile, and the standard data profile and user data profile. This is realized by defining item relations with (ordering company data profile). By doing this, between the data items between the data of the ordering company and the data of the ordering company via the standard data profile without defining the field relation between the data profile of the ordering company and the user data profile. Related information (link information) can be acquired, and data conversion and translation can be realized. A standard data profile can be created for each industry.

FIG. 32 is a block diagram showing a relationship between a general table structure and three physical tables of the data management system according to the fifth embodiment of the present invention.
As shown in FIG. 32, the data management system (“eDIY” in FIG. 31) realizes data conversion and translation by dividing a general table structure and data stored in it into three physical tables. . That is, as described above, the data management system includes a row management (ROW) table for storing indexes, a column management (COLUMN) table for storing data item contents, and a value management (CELL) for storing data (item values). ) Table has three tables. Of the three tables, the column management table corresponds to a table that stores the data item definition of each data profile. A company profile is created including the definition of relationships between the records in this column management table (the item relationship definition (COLUMN_CHAIN) table in FIG. 32).

FIG. 33 is an explanatory diagram showing the concept of three physical tables of the data management system according to the fifth embodiment of the present invention.
The concepts of the three tables in FIG. 32 can be represented by rows (rows), columns (columns), and cells of a table handled in the relational database, as shown in FIG. That is, as described above, the data management system manages the column data items (columns) not as data items that require data design work but as item values that can be easily input and edited as data input work. Store in the table, store the index (row ID) of each record to be managed (read record) in the row management table, and manage the value of the item value stored in the cell where the data item (column) and row ID intersect Store in table (identified by column ID and row ID).

FIG. 34 is a block diagram for explaining the processing of the record hierarchical structure in the three physical tables of the data management system according to the fifth embodiment of the present invention.
Here, as described above, various data exchanged in electronic commerce often has a hierarchical structure as shown in FIG. 34 (see FIG. 15). In the case where there is a hierarchical structure between data stored in the row management table, the data management system uses a record sub ID, which is a code representing the record hierarchy of the column management table, as shown in FIG. In the row management table, the parent record sequence No. This can be dealt with by ensuring a parent-child relationship by defining (the serial number of the record that becomes the parent of the record). However, as will be described later, a separate table (row relation management table) is prepared by taking out related information between the records such as the hierarchical relation and parent-child relation or between tables from the row management table. It is preferable to make it correspond.

FIG. 35 is a flowchart showing a business flow when the data management system according to Embodiment 5 of the present invention is applied to a distribution support system for a distribution company.
An improved version of the data management system ("eDIYplus") is a package that supports the logistics business process in which data exchanged by the above-mentioned data management system ("eDIY") is stored in a client-side database and can be used effectively. It is. This improved version of the data management system supports a business process indicated by a rectangle surrounded by a thick line in FIG. That is, the data management system checks the order contents at the time of order receipt, provisional provisioning of inventory, location instruction at the time of delivery and provision of inventory, inspection of shipment and correction of shipment quantity, issuance of PD label, issuance of corrected invoice, etc. It is possible to respond to the introduction according to the information level of the user company.

FIG. 36 is an explanatory diagram showing a company management (CUSTOMER) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention.
As shown in FIG. 36, the company management (CUSTOMER) table includes, as its data items (columns), “company code”, “company name”, “〒 (zip code)”, “address”, “TEL (phone number). ) ”,“ Person in charge ”,“ mail ”,“ company classification ”, and the like. In addition to the data items shown in FIG. 36, the company management table of FIG. 36 defines other data items (such as “valid date”) as described in the table of FIG. Yes. The company management table stores values (data item values) corresponding to each data item in each row (each record) of the table (“000000”, “information center”, etc.). Here, the value “000000” of the company code, which is a data item of the company management table, corresponds to the management center (eDIY support center in FIG. 31, displayed as “information center” in the table) that manages the data management system, and is standard. Define and manage each profile information such as data profile. Further, the value “111111” of the company code corresponds to the ordering company (ordering company in FIG. 31) of the data (ordering data etc.) managed by the data management system, and all of the data to be managed by this data management system belongs to it. Ordering companies (customer companies for user companies) are registered. The value “999999” of the company code corresponds to the user company (order receiving company in FIG. 31) that uses the data management system. When a company is added or deleted, or the company information of a registered company is changed, the value of the corresponding data item in the company management table is updated.

FIG. 37 is an explanatory diagram showing a data exchange management (EXCHANGE) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 37, the data exchange management (EXCHANGE) table includes, as its data items (columns), “partner company (code)”, “user company (code)”, “data type (code)”, “ Protocol, transmission direction, transmission size, slip form, etc. are defined. The data exchange management table of FIG. 37 is not shown in addition to the data items shown in FIG. 37, but other data items (“valid date”, “product code conversion” as described in the table of FIG. 29). File name ”,“ business partner / company code ”, etc.). The data exchange management table stores values (data item values) corresponding to each data item in each row (each record) of the table (“11111101”, “999999991”, etc.). In the data items of the data exchange management table, “partner company (code)” is a company (for example, ordering data) that is a transmission source (sending side) of management target data (ordering data, arrival schedule data, etc.) Is a version code (2 digits) indicating the version (version) of the data profile or column definition of the management target data to the company code (6 digits) of the ordering company or the ordering company in the case of planned arrival data). . In the data item of the data exchange management table, “user company (code)” is a company (for example, an order received in the case of ordering data) that is a transmission destination (receiving side) of management target data (ordering data, delivery data, etc.) A version code (2 digits) indicating the version (version) of the data profile or column definition of the data to be managed is added to the company code (6 digits) of the company or the ordering company in the case of planned arrival data. In addition, the “partner company (code)” and “user company (code)” are assigned to the management center that manages the standard data profile in addition to the ordering company and the ordering company. In this case, the management center code ( (6 digits) is a version code (2 digits) indicating the version (version) of the standard data profile managed by the management center. The data exchange management table shows whether there is a transaction between the customer company and the user company when data of the customer company is converted into data of the user company (data exchange). ) Is checked between data exchanges (such as when ordering data is read) and the company code and user code actually entered at the time of data reading are determined. It is determined whether or not the transaction (data exchange) exists in the data exchange table, and only when the transaction exists, the data exchange is executed using the table management table described later, and the transaction does not exist In this case, it is used for a predetermined process such as executing an error process.

  Here, for example, the record in the first row of the data exchange management table indicates that the company (ordering company) with the supplier company code “11111101” sends the data type code “9” to the company (order receiving company) with the user company code “9999901”. 20 ”data (ordering data) is transmitted according to the transmission protocol“ 2 ”(transmission direction“ R ”), that is, the ordering data of the ordering company is received in the ordering data specification format (designated data format). Indicates the case of conversion to The record in the second row of the data exchange management table shows that the company (ordering company) with the supplier company code “11111101” has the data type code “20” sent to the company (management center) with the user company code “00000001”. Data (ordering data) is transmitted (transmission direction “R”) in accordance with the transmission protocol “2”, that is, the ordering data of the ordering company is converted into data in the standard data profile format of the management center. Further, the record in the third row of the data exchange management table shows that the company with the supplier company code “999999991” (the ordering company that is the user company) sends the data type code to the company (ordering company) with the use company code “11111101”. The data “30” (scheduled arrival data) is transmitted (transmission direction “S”) in accordance with the transmission protocol “2”, that is, the planned arrival data of the ordering company is converted into the scheduled delivery data of the ordering company in the data profile format. Indicates the case of conversion. In this way, for all data types, the relationships between all pairs of business partners and users who have transactions (data exchange) are stored in the data exchange management table. The data management system not only exchanges data (reads data) between the ordering company specification format (ordering company data profile) and the ordering company specification format (ordering company data profile), but also the ordering company specification format. Data exchange management table for exchanging data between (ordering company data profile) and standard data profile, and data exchange between specified format of ordering company (ordering company data profile) and standard data profile Stores the relationships between all pairs of business partners and users who have transactions (data exchange). In addition, for the transaction (data exchange) of each row in the data exchange management table, the slip format (use slip name) and PD label (use PD label name) used are also stored in the data exchange management table, and the data display after data conversion is performed. A slip to be used is referred to by a display program of the data management system at the time of (printing or screen display). Note that when the relationship between companies that require data exchange is added or deleted, or when the contents of the registered slip format or the like are changed, the value of the corresponding data item in the data exchange management table is updated.

FIG. 38 is an explanatory view showing a data type (DATA_KIND) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 38, the data type (DATA_KIND) table includes “data code”, “data type (name)”, “valid date / time”, “valid date / time” as its data item (column). ”,“ Registration date / time ”,“ update date / time ”,“ deletion date / time ”,“ access control ”,“ registrant information ”, and the like. In addition to the data items shown in FIG. 38, the data type table of FIG. 57 defines other data items (“data type kana”) as described in the table of FIG. 29, although not shown. Yes. The data type table stores values (data item values) corresponding to each data item in each row (each record) of the table (“00”, “others”, etc.). Here, the date / time information including “valid date / time”, “valid date / time”, “registration date / time”, “update date / time”, and “deletion date / time” is not only the data type table, but also this data management system. Is defined as the data items of all the tables used, and the values of the data items are stored, for example, providing information that can limit the validity period of the column management table definition (the period during which the column definition can be used), etc. Therefore, it is used for version management of column definitions. In addition to “Effective Date / Time (Own)”, “Effective Date / Time (Own)”, “Registration Date / Time”, “Update Date / Time”, and “Delete Date / Time”, all tables of this data management system include “Access Control”. ”And“ registrant information ”are provided, and the value of the data item is stored. When referring to a predetermined row of another table that defines a data type in a column and stores its value, such as a data exchange management table, the data type table is referenced using the data type code as a key, and the other table's Information on the data type stored in the predetermined row is acquired from the data type table.

FIG. 39 is an explanatory diagram showing a table management (TABLE) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 39, the table management (TABLE) table includes “company (version) (= company code + version information)”, “type (= data type code)”, “branch” as its data items (columns). Number (= code indicating record related information) ”,“ record name ”,“ control information (= record control information) ”,“ size (= record size) ”,“ target (= target object) ”,“ header (= "Presence / absence of header)", "Previous R (= previous record designation)", "Rear R (= following record designation)", etc. are defined. In addition to the data items shown in FIG. 398, the table management table shown in FIG. Date and time (To) "etc.). In the table management table, values (data item values) corresponding to the respective data items are stored in the respective rows (each record) of the table (“00000001”, “20”, etc.). Of the data items in the table management table, “company (version)” corresponds to the company code (company code 6 digits + version code 2 digits) in the data exchange management table. The “type” identifies the data type targeted by the data management system, and corresponds to the data type in the data type table. The “branch number” indicates record-related information having a relationship such as a parent-child relationship or a hierarchical structure, and uniquely indicates a hierarchy or the like in management target data such as ordering data. The “company (version)”, “type”, and “branch number” constitute a table ID. The “branch number” is a sub-ID that uniquely identifies the table ID within the same data type in the company having the company (version) code, and is stored in the table management table.

  The “control information” is record analysis information similar to the record control information described above in the table of FIG. 29, and information for identifying the record in the row to which the control information belongs (the relevant information Stores the byte position from the beginning (0) of the record and the character string code to be checked). For example, in the case of the record on the first line (the “standard-order-file header” record with the table ID “00000001201”), the data management system refers to the table management table when reading data, and starts from the top of the read record. If the character string code at the position “0” is “FH20”, that is, if the first character string code is “FH20”, the record is determined to be a “standard-order-file header” record. “Size (record size)” indicates the size (byte) of the record. The data management system refers to the table management table when reading data, and sets the “record (size)” of the table ID according to the record (specific table ID) determined by the “control information (record control information)”. The read data is divided by the designated record size to make one record of the table ID. “Target” indicates the target object of the record of the table ID, that is, which record is the slip record or the slip detail line record, and corresponds to the object ID of the target management table described later. The data management system refers to the table management table when reading data, and based on the value of “target” of the record (record of the specific table ID) determined by the “control information”, the target object (slip, Packaging etc.). The table management table stores records of all companies grasped (handled) by the data management system. That is, the table management table includes all record related information such as record hierarchy and parent-child relationship of data of all data types for the ordering company, the user company (order receiving company), and the data management center (equivalent to the above eDIY). The data definition information as described above is stored for each table ID.

  FIG. 40 is an explanatory diagram showing a standard data profile portion of a column management (COLUMN) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 41 is an explanatory diagram showing an ordering company data profile portion of the column management (COLUMN) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention. FIG. 42 is an explanatory diagram showing an order enterprise data profile portion of a column management (COLUMN) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.

  As described in the first to fourth embodiments, the column management (COLUMN) table stores the standard data profile, the ordering company data profile, and the ordering company data profile as one table. The table of FIG. 42 constitutes one table (illustrated in three parts for convenience of explanation and for the relationship of the paper size). As shown in FIGS. 40 to 42, the column management table includes “column ID”, “company (version) (= company code + version information)”, “type (= data type code) as its data items (columns). ) ”,“ Branch number (= record related information) ”,“ serial number (= sequence number) ”,“ name (= data item name) ”,“ data type (= data attribute) ”,“ conversion (= conversion) (Method) ”,“ position (= position) ”,“ maximum length (= length) ”,“ minimum length (= length (minimum)) ”, and the like. The column management tables of FIGS. 40 to 42 are not shown in addition to the data items shown in FIGS. 40 to 42, but as described in the section of the table of FIG. 29, other data items (“ “Related Flag”, “Related Method”, “Related Item”, “Identifier Creation Order”, “Basic Item Specification Order”, “Column Sub ID”, Others, “Valid Date / Time (Own)”, “Valid Date / Time (To)”, etc. Date and time information). The column management table stores values (data item values) corresponding to each data item in each row (each record) of the table (“1201001”, “00000001”, etc.). In the data item of the column management table, “company (version)” corresponds to the company code (company code 6 digits + version code 2 digits) in the data exchange management table and table management table. The “type” corresponds to the data type of the data type table and the table management table. The “branch number” corresponds to the “branch number” in the table management table. As described with respect to the table management table, a table ID is composed of the “company (version)”, “type”, and “branch number”, and a code that uniquely identifies a data item is added to the end of the table ID. It becomes a column ID.

  Further, as described above, the “sequential number” is configured to indicate the output order of the data items (fields in the record) in the record of the same table ID (preferably), but indicates the storage order. You may comprise as. When the branch number indicates the storage order, the branch number is used as a code at the end of the column ID. In this case, for example, when a record of a certain table ID is composed of a total of 16 data items (fields), the serial numbers from “1” to “16” are stored as the value of “serial number (sequence No.)”. . A code corresponding to each data item in the same record on a one-to-one basis is configured by a combination of a table ID and a serial number (a series of codes). Here, the column ID is also a code corresponding to each data item in the same record on a one-to-one basis, and uniquely identifies a data item of a record of a specific data format, that is, a data item of a record of the same table ID. However, the data item of the record of the specific data profile can be uniquely specified by the combination of the table ID and the serial number. In the fifth embodiment, the column ID is a code that is automatically generated according to a creation standard that integrates and simplifies the combination code of the table ID and the sequence number. For example, in the case of the record on the first line, “1” of the company (version) code “00000001”, the data type “20”, “1” corresponding to the branch number “1”, and the serial number “1”. A column ID “1201001” is generated from the corresponding “001”. When the branch number is “2”, “2” is assigned to the corresponding portion of the column ID, and “3” is assigned to the corresponding portion of the column ID when the hierarchy code is “3”. Corresponding to such column IDs on a one-to-one basis, the data item names of a series of data items unique to each record such as a file header record, a slip header record, and a slip detail row record are “sequentially arranged”. Corresponding to the order of “No.”, it is stored as an item value of “Name” (“Record classification”, “Data type”, “Data creation date”...).

  Next, in the column management table, a data item of “related flag” is provided, and a data item of a certain column ID is linked (chained) between items with the standard data profile in the item related definition table Is turned on. As a result, it is possible to link only the necessary data items of the records of each data format (data profile) with the corresponding data items of the standard profile via the “related flag”. When referring to the field-related definition table in data conversion between company data profile record and order company data profile record, refer to only the link between required data items without referring to the link between all data items. Thus, the processing load can be reduced. The column management table is provided with a “conversion method” data item, and stores the method name (column value (COLUMN_VALUE), etc.) to be used when the value of the item value of a certain column ID needs to be converted. To do. For example, as described with reference to the item value management table of FIG. 21, when the meaning of the item value is different among a plurality of data having different data formats, for example, the column value of the ordering company data profile is “0”, When the column value of the corresponding standard data profile is “a” and the column value of the ordering company data profile corresponding to this is “a”, the “conversion method” of the column ID of the ordering company data profile, A character string of “column value” or “COLUMN_VALUE” is stored in the “conversion method” of the column ID of the standard data profile and the “conversion method” of the column ID of the order receiving company data profile, respectively. For example, when the data management system converts ordering data in the ordering company data profile to ordering company specified data in the ordering company data profile, the method name is stored in the “conversion method” of the record of the ordering company specifying data in the column management table. With respect to the column ID, the item relation definition table is referenced, and the column ID (target column ID) of the standard data profile corresponding (linked) to the column ID (trigger column ID) and the ordering company linked to the target column ID When the column IDs of the data profile are extracted, the conversion process of the meaning of the item value is executed as described with reference to FIG. 21 with reference to the rows of the three column IDs of the item value management table.

  Next, when the column management table is provided with a data item of “identifier creation order” and records having a certain table ID are stored in the row management table, a predetermined ID of the table ID is set as the “identifier” of the row management table. When the data items are stored, the order of the data items (the order of the data items constituting the “identifier”) is stored. The column management table is provided with a data item of “basic item specification order”, and indicates the number of basic information (basic item value) of the row management table in which the item value of the data item of a certain column ID is copied. The code is stored. That is, in addition to the row ID and identifier as an index, the row management table includes basic information of each read record (for example, the slip header record slip number, order date, delivery date, inspection date, etc.) Code, product name, order quantity, inspection quantity, etc.) are stored as a predetermined number of “basic item values” (= data items), but the data item value of the specific column ID is copied to such basic item values. When storing, the value of the data item of the column ID is copied to the basic item value of the row management table in the order specified in the “basic item specifying order”. In addition, a data item of “column sub ID” is provided in the column management table. The column sub ID corresponds to the column sub ID. When the item value of the data item of a certain column ID is stored as the value of the “match item” (= data item) of the row management table, the column ID Specifies the object ID value of the target object. In other words, in addition to the row ID as an index, the row management table determines, for example, a difference in quantity (insufficient quantity) between the ordering data and the planned arrival data for each read record and corrects it to a delivery note etc. In order to describe the information, the value of “identifier” that becomes the search key when matching the correspondence record of ordering data and scheduled arrival data and the value of “match item” to be matched are stored. Then, the value of the object ID of the target object of the column ID is stored as the value of “match item” in the row management table.

FIG. 43 is an explanatory diagram showing an item value management (COLUMN_VALUE) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 43, the item value management (COLUMN_VALUE) table defines “ID”, “column ID”, “column value”, “standard value”, “meaning” and the like as the data item (column). ing. The item value management table in FIG. 43 is not shown in addition to the data items shown in FIG. 43, but other data items (“remarks”, “reference flags” as described in the section of the table in FIG. 29). ”,“ Valid date / time (from) ”,“ valid date / time (to) ”, etc.). The item value management table stores values (data item values) corresponding to each data item in each row (each record) of the table (“245”, “1111110120201600”, etc.). The item value management table is used for value conversion processing in the same manner as described with reference to FIG.

FIG. 44 is an explanatory diagram showing an item relation definition (COLUMN_CHAIN) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 44, the item relation definition (COLUMN_CHAIN) table includes, as its data items (columns), “ID”, “trigger column ID”, “serial number (= sequence No)”, “target column ID”, “Function (= function code)”, “Parameter 1”, “Parameter 2”, “Parameter 3”, etc. are defined. The item relation definition table of FIG. 44 is not shown in addition to the data items shown in FIG. 44, but other data items (“parameters 4 to 10”, “Remarks”, “Effective date / time”, “Effective date / time”, etc.) are defined. The item relation definition table stores values (data item values) corresponding to the respective data items in the respective rows (each record) of the table (“54”, “11111101201003”, etc.). The item relation definition table is used for data conversion processing between the ordering company data profile and the ordering company profile via the standard data profile in the same manner as described with reference to FIG. That is, as indicated by a box in FIG. 44, the ordering company designates the value of the data item of the column ID “11111101201003” of the ordering data in the ordering company data profile via the column ID “1201003” of the standard data profile. When converting to the value of the data item of the column ID “999999901001003” of the order data profile to be received, the data management system uses the column ID “9999991201003” of the ordering company data profile as a trigger to the target ID “1201003” of the standard data profile The value of the data item of the column ID “11111101201003” of the ordering company data profile stored according to “1 (storage)” of “function code” is acquired according to “2 (acquisition)” of “function code”. As a result, the value of the data item of the column ID “11111101201003” of the ordering company data profile is stored in the value of the data item of the column ID “999999901001003” of the order-receiving company data profile, and displayed and output as a set with the data item. Note that “parameters 1 to 10” store predetermined values when the parameters of the function are required according to the function contents of the “function code”, and the data management system stores the “function code” in the item relation definition table. In accordance with the value of “”, the function contents of the function management table are referred to, and the process of the function is executed according to the value of the parameter.

FIG. 45 is an explanatory diagram showing a function management (FUNCTION) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention.
As shown in FIG. 45, the function management (FUNCTION) table includes “function (= function code)”, “function (= function content)”, “detail (= help)”, and the like as its data items (columns). Defined. In addition to the data items shown in FIG. 45, the function management table shown in FIG. 45 is not shown, but as described in the table section of FIG. 29, other data items (“valid date (self)”, "Effective date (to)" etc.) is defined. The function management table stores values (data item values) corresponding to the respective data items in the respective rows (each record) of the table (“1”, “store”, etc.). The functions stored in the function management table are defined in advance and stored as data item values in consideration of processing required for data managed by the data management system. That is, in the past, functions and parameters that were defined in the program according to the required processing are moved out as data item values in the function management table in this data management system, and the function management table is referred to. Necessary processing is executed. Therefore, when the contents of required processing are added, deleted, changed, etc., the function stored as the item value in the function management table is not required without the troublesome work of changing the program itself as in the past. By adding, deleting, or changing, or adding, deleting, or changing the value of a parameter stored as an item value in the item relation definition table, it is possible to easily cope with a change in processing.

FIG. 46 is an explanatory diagram showing an object management (OBJECT) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 46, the object management (OBJECT) table includes, as its data items (columns), “ID (= object ID)”, “object name”, “position (= position)”, “key content”, and the like. Is defined. The object management table in FIG. 46 is not shown in addition to the data items shown in FIG. 46, but other data items (“reference flag”, “valid date / time”, as described in the table of FIG. 29). (Self) "," Effective Date (To) ", etc.). The object management table stores values (data item values) corresponding to the respective data items in the respective rows (each record) of the table (“3”, “GTIN code”, etc.). “ID (= object ID)” corresponds to “target (= target object)” in the table management table and “column sub ID” in the column management table. “Position” is defined in the item value (“key content”) of the column item (GTIN code, id slip, id slip detail line, etc.) corresponding to the object of the object ID. For example, in the case of an id slip Indicates the ordering company code + (store code) + slip NO) as the value of the “match item” in the row management table. For example, the item value of the object “store code” of the object ID “11” is the item value of the first matching item (matching item value 1) of the corresponding object (slip header record and slip detail row record) in the row management table. The item value of the object “slip number” of the object ID “20201” is the second matching item (matching item value 1) of the corresponding object (slip header record and slip detail row record) in the row management table. Stored as an item value, the item value of the object “line number” of the object ID “201011” is the item value of the third matching item (matching item value 1) of the corresponding object (slip detail row record) in the row management table. And the item value of the object “GTIN code” of the object ID “3” is It is stored as the item value of the object 4 th abutting items (document items line records) (butting item value 4) to the management table corresponding. The item value of “object ID” stored as the item value of “match item” in these row management tables is the file header record, slip header record, slip detail row record, invoice header record that is the management target of the data management system, Each target object (record) is uniquely identified as an identifier of a packing record, a packing detail record, or the like. And, for example, if there is a difference (out of stock) in the quantity between the order quantity specified in the slip details with order data and the actual delivery quantity in the slip details in the planned arrival data, it is stored in the line management table. Reconcile both voucher items with reference to the reconciliation item value and check their quantity (for example, the order quantity and the acceptance quantity stored as the basic item value in the row management table), and automatically deliver the delivery quantity of the expected arrival voucher Correction processing can be performed automatically.

  Here, as the system management target, for example, “11, store code, 1” (object ID, object name, position order), “20201, slip number, 2”, “202011, line number, 3”, “ 3, GTIN code, 4 ”,“ 40201, packing code, 5 ”,“ 20101, order date, 6 ”,“ 30101, shipping date, 7 ”,“ 30201, shipping instruction No. 8, ”,“ 302011, shipping There are “instruction line No. 9”, “70111, payment details, 10”, and any one of these item values corresponding to each record to be managed (record of a predetermined column definition identified by its table ID). One or more (may be zero) is automatically assigned and stored as the item value of the corresponding matching item in the row management table according to the position (position). Other than these, for example, “1, ordering company code (code indicating ordering company)” (order of object ID, object name, key content), “2, ordering company code (ordering company) ”,“ 10, product (indicating transmission event of product information. 10 + ordering company code + ordering company code + transmission date) ”,“ 20, ordering (indicating reception event of ordering information. 20 + ordering company code) + Ordering company code + ordering date) "," 30, delivery notification (ASN) (indicating a delivery event for delivery notification. 30+ ordering company code + ordering company code + scheduled delivery date) "," 40, packing details (SCM) (Indicates a sending event for packing details. 40 + ordered company code + ordered company code + shipping date) ”,“ 50, receipt (represents reception information reception event. 50+ "Note company code + ordering company code + acceptance date)", "60, billing (indicating sending event of billing information. 60 + ordering company code + ordering company code + billing date)", "70, payment (payment information receiving event) 70 + ordered company code + ordered company code + payment notification date) ”,“ 80, returns (return event received information 80 + ordered company code + ordered company code + return date) ”,“ 2020, id slip ” (Indicates the slip uniquely in the system. Ordered company code + (store code) + slip NO) ”,“ 2030, id slip details line (shows the slip details uniquely in the system. Ordered company code + (store code) + Slip NO + slip line NO) ”,“ 4010, id shipment (shipping unit uniquely shown in the system. Ordering company code + store code + shipping date) ”,“ 4020, id packing (Package is uniquely indicated in the system. Ordering company code + (store code) + packing NO) "," 4030, id packing details (packing details are uniquely indicated in the system. Ordering company code + (store code) + "Packing NO + slip NO + slip line NO)", "6011, billing (indicating monthly billing summary)", "6020, id billing (indicating billing uniquely within the system. Ordering company code + (store code) + billing Target period), "6030, id billing details (indicating billing uniquely in the system. Ordering company code + (store code) + billing target period + subject code)", "7011, payment (monthly payment summary ”,“ 7020, id payment (indicates the slip uniquely in the system. Ordering company code + (store code) + payment target period) ”,“ 7030, id payment details (indicates the slip uniquely in the system). Ordering company code + (store code) + payment period + subject code) "," 60111, billing details (show billing details for each month) "," 402011, packing details (code showing packing details) " Corresponding to each management target record (record of a predetermined column definition identified by the table ID), any one of these item values is the “identification value” of the corresponding “identifier ID” of the row management table. It is automatically assigned and stored as an item value.

FIG. 47 is an explanatory diagram showing a row management (ROW) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 47, the row management (ROW) table includes “row group”, “serial number (= sequence No.)”, “row title”, “company (version) (= company) as data items (columns). "Code + version information)", "type (= data type)", "branch number (= record related information", "parent S (= parent record sequence No)", "FS (= sequence number in the same record)", “Identifier (= identifier value)”, “match value 1 (= match item value 1)” (to “match item value n (for example, match item value 10)”, “basic value 1 (= basic item value 1)” ( ~ "Basic item value n (for example, matching item value 5"), etc. The row management table of Fig. 47 is not shown in addition to the data items shown in Fig. 47, but is shown in Fig. 29. Other data items ("identifier ID", " Define bespoke name ”,“ related method ”,“ related information ”,“ remarks ”,“ reference flag ”, and other date / time information such as“ valid date / time ”and“ valid date / time ”. In the row management table, values (data item values) corresponding to the respective data items are stored in the respective rows (each record) of the table (“1111101-999999-50-051207-201914”, “1”). "... etc." In the data items of the row management table, "row group" is a code that is automatically generated (numbered) every time the data management system reads one record in accordance with a predetermined creation standard. The row group is, for example, 8 digits of the ordering company code (+ version) + 6 digits of the ordering company code + 2 digits of the data type + 6 digits of the data reading date + data reading Time It can be automatically generated as a unique code from 6 digits (hour, minute, second), and the same row group is assigned to all records of data (order data etc.) read at one time. A record having the same row group is a management group of one unit to be managed as storage data by the data management system.Next, “sequential number” is a serial number (record) of the record in the same row group. For example, when the read data is composed of 100 records, serial numbers “1” to “100” are assigned as item values of “serial number (sequence No)” in the order of the read records. A group ID and a sequence number (sequence number) form a row ID, and the row ID indicates what number of input data (read data) the record is. The code corresponding to each read record on a one-to-one basis is constituted by the row ID. The “company (version)” corresponds to the company code (company code 6 digits + version code 2 digits) in the data exchange management table and the table management table. The “type” corresponds to the data type of the data type table and the column management table. The “branch number” corresponds to the “branch number” in the table management table and the column management table. As described for the table management table, the “company (version)”, “kind”, and “branch number” constitute a table ID. In the row management table, when the table management table is referred to when reading data, the table ID is automatically set for records that match (collate) with the column definition of a specific table ID based on the value of “record control information”. Is granted. At this time, the item value of “record name” (see table management table) assigned to the table ID is copied as the item value of “row title” in the row management table.

  Next, “parent S (parent record sequence No.)” indicates the value of “serial number (sequence No.)” of the parent record (higher-level record) to which the storage record depends. For example, in the case of the record in the first row (the value of “serial number (sequence No)” is “1”), since it is a file header record (FH), there is no parent record, and “parent S (parent record sequence) No) ”becomes“ 0 ”. In the case of the record on the second line (the value of “sequence number (sequence No)” is “2”), since it is a slip header record (DH), a file header record exists as a parent record, and “parent S ( "Parent record sequence No)" is "1" which is the value of the "serial number (sequence No)" of the parent record. Further, in the case of the record on the third line (the value of “sequence number (sequence number)” is “3”), since it is a slip detail line record (DD), the slip header of the slip to which the slip detail line belongs as a parent record. There is a record, and “parent S (parent record sequence No.)” is “2” which is the value of “serial number (sequence No)” of the parent record. Similarly, in the case of the record on the ninth line (the value of “serial number (sequence number)” is “9”), since it is a slip header record (DH), a file header record exists as a parent record, and “parent S “(Parent Record Sequence No.)” is “1” which is the value of “Serial Number (Sequence No)” of the parent record. Further, in the case of the record on the 10th line (the value of “serial number (sequence No.)” is “10”), since it is a slip detail line record (DD), the slip header of the slip to which the slip detail line belongs as a parent record. There is a record, and “parent S (parent record sequence No.)” is “9” which is the value of “serial number (sequence No)” of the parent record. Next, “FS (sequence number in the same record)” indicates a sequence (order) in the same group to which the storage record belongs. That is, in the case of the record in the first row (the value of “serial number (sequence number)” is “1”), it is a file header record (FH), one for one read data (stored record group of one management group). However, the value of “FS (Sequence No. in Same Record)” is “1”. In the case of the records in the 2nd, 9th, and 16th rows (“sequence number (sequence number)” is “2”, “9”, “16”), the slip header record (DH) is used respectively. Since there are a plurality of numbers, “FS (Sequence No. in Same Record)” in order of increasing “Sequence Number (Sequence No)” in order to indicate the sequence (order) in the same group (ie, slip header group). Values are assigned consecutively such as “1”, “2”, “3”. In addition, in the case of the records in the 10th line, the 11th line, etc. (the values of “serial number (sequence number)” are “10”, “11”. In order to indicate the sequence (order) in the same group (that is, the slip line group), the value of “FS (sequence number in the same record)” is shown in ascending order of the value of “sequence number (sequence No)”. Are continuously given as “1”, “2”.

  Next, “identifier (identifier value)” indicates the identifier value of the storage record. When the row management table is created (when each record of data is read), the data management system refers to the “identifier creation order” in the column management table and refers to the “record control information” in the table management table. Corresponding to the table ID of the read record (record to be managed), the values of the data items of the specified table ID are sequentially assigned according to the order specified in the “identifier creation order” of the table ID of the column management table. In combination, the “identifier” value of the row management table is automatically generated. For example, in the column management table, for the file header record (table ID “9999901501”), “ordering company code”, “data type”, and “data creation date” in the “identifier creation order” are “1”, Since the values are specified in the order of “2” and “3”, the values of these data items (“111111”, “50”, “20050817”) are combined in order to generate the identifier value of the row management table. , “0” (“object ID” of the system object table) in the “identifier ID” of the row (record) of the table ID, “ordering company code—data type—data creation date” in “identifier name”, “111111-50-20050817” is stored in the “identification value” (refer to the record in the first row of the row management table).Similarly, in the column management table, for the slip header record (table ID “99999015011”), the “slip number” is specified as “1” in the “identifier creation order”, so the value of this data item (“49218389”) ) Is added to the identification value of the file header record to generate the identifier value of the row management table, and “2020” (“object” of the system target object table) is set in the “identifier ID” of the row (record) of the table ID. "ID"), "Ordering company code-data type-data creation date-slip number" in "identifier name", and "111111-50-20050817-92218389" "in" identification value "(row management table) (Refer to the record on the second line.) Similarly, in the column management table, for the slip detail row record (table ID “9999990150111”), “line number” and “GTIN” are respectively designated as “1” in the “identifier creation order”. Are added to the identification value of the slip header record to generate the identifier value of the row management table, and the “identifier ID” of the row (record) of the table ID is “ 2030 ”(“ object ID ”in the system target object table),“ ordering company code−data type−data creation date−slip number−line number−GTIN ”in“ identifier name ”, and“ 111111− ”in“ identification value ”. 50-20050817-49218389-02-0493606687272 ” Each stored (In FIG. 66, omitted the line number). The identification value assigned to each record of the row management table in this way is, for example, when a predetermined item value (order quantity, inspection quantity or scheduled delivery quantity, etc.) of order data and arrival schedule data is matched. Used as a search key.

  Next, “match value 1 (match item value 1)” to “match item value n (for example, match item value 10)” stores the match item values used when the records in each row are matched as described above. To do. That is, when the row management table is created (when each record of data is read), the data management system uses the column ID of the read record (managed record) determined by referring to the “record control information” of the table management table. Correspondingly, the value of the object ID stored in the “column sub ID” for the data item of the column ID in the column management table is referred to, and the “position” of the corresponding “object ID” of the target management table for the object ID. ”, The value of the object corresponding to the object ID is stored in any of“ match value 1 ”to“ match value n ”of the corresponding record in the row management table at the position (position). At this time, in the column management table, the value of the column ID corresponding to the object is acquired from the read record at the time of data analysis / reading (the corresponding item value of the record is acquired), and the object corresponding to the object ID Is stored in the “match item value” of the row management table. For example, in the column management table, for the slip header record (table ID “99999015011”), the object ID “11” of the order store code (store code) is specified in the “column sub ID”. The system object management table is referred to for a certain object ID “11”, and “position (position)” as a match item value of the row management table for the object ID “11” is determined and the object (store code) is determined. The column ID value (“100”) is acquired from the read record, and the value “100” is stored in “match item value 1” as the first match value in the row management table (second row of the row management table). Record reference). In addition, “basic value 1 (basic item value 1)” to “basic item value n (for example, matching item value 5)” are read from the read record according to the order specified in “basic item specification order” of the column management table. Basic item values are extracted and stored.

  Next, “basic item designation order” indicates to which number of basic information (basic item values) of the row management table the item value of the data item of the column ID is copied. That is, in addition to the row ID as an index, the row management table includes basic information of each read record (for example, a slip number of a slip header record, an order date, a delivery date, an inspection date, etc., a product code of a slip detail row record, (Product name, order quantity, inspection quantity, etc.) are stored as a predetermined number of "basic item values" (= data items), but the values of the data items of specific column IDs are copied and stored in these basic item values In this case, the value of the data item of the column ID is copied to the basic item value of the row management table in the order specified in the “basic item specifying order”. The “column sub ID” is an object of the “target object” of the column ID when the item value of the data item of the column ID is stored as the value of the “match item” (= data item) of the row management table. Specify the ID value. In other words, in addition to the row ID as an index, the row management table determines, for example, a difference in quantity (insufficient quantity) between the ordering data and the planned arrival data for each read record and corrects it to a delivery note etc. In order to describe the information, the value of “match item” which becomes a search key when matching corresponding records of order data and arrival schedule data is stored. In such a case, the object Uto ID of the target object of the column ID is stored. Is stored as the value of “match item” in the row management table. For example, in the column management table, for the file header record (table ID “9999901501”), “ordering company code”, “ordering company code”, “data type”, “data creation date”, “basic information creation order”, Since the “number of records” is specified in the order of “1”, “2”, “3”, “4”, “5”, the values of these data items (“111111”, “999999”) , “50”, “20050817”, “61”) are stored in that order in the “basic item value 1” to “basic item value 5” of the record of the row management table, respectively. Similarly, in the column management table, for the slip header record (table ID “99999015011”), “slip number”, “order date”, “delivery date”, and “acceptance date” in the “basic information creation order” are , “1”, “2”, “3”, “4”, the values of these data items (“492218339”, “200550113”, “20050119”, “20050119”) are In this order, they are stored in “basic item value 1” to “basic item value 4” of the record in the row management table. Similarly, in the column management table, for the slip detail row record (table ID “9999990150111”), “GTIN”, “Standard Kana”, “Product Name Kana”, “Order Quantity”, “Acceptance” in “Basic Information Creation Order”. Since the “quantity” is specified in the order of “1”, “2”, “3”, “4”, “5” respectively, the values of these data items (“0493606927217”, “*** ( Standard name) ”,“ *** (product name ”,“ 30 ”,“ 30 ”) are stored in that order in the“ basic item value 1 ”to“ basic item value 5 ”of the corresponding record in the row management table. To do.

FIG. 48 is an explanatory diagram showing a value management (CELL) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention.
As shown in FIG. 48, the value management (CELL) table includes “row group”, “row ID”, “company (version) (= company code + version information)”, “type” as its data items (columns). (= Data type), “branch number (= record related information)”, “serial number (= cell sequence No.)”, “parent S (= parent record sequence No.)”, “FS (= sequence number within the same record level) ) ”,“ Value 1 ”,“ value 2 ”,“ value 3 ”,“ value 4 ”,“ value 5 ”(to“ value n (for example, value 30)), etc. ”are defined in FIG. The value management table is not shown in addition to the data items shown in FIG. 48, but other data items (“value 01-access control”... Method, Related Item, Effective Date / Time (Own), Effective Date / Time (To), etc.) The value management table stores values (data item values) corresponding to the respective data items in the respective rows (each record) of the table (“1111101-999999-50-051207-201914”, “ In the data item of the row management table, “row group” corresponds to “row group” of the row management group, and “row ID” is “serial number ( = Sequence No. ", each read record (stored record) is uniquely indicated by the composite key of the row group and the serial number (that is, row group + serial number = row ID). Version) (company code) "corresponds to the data exchange management table and the company code (company code 6 digits + version code 2 digits) in the table management table, and" type "is the data type The “branch number” corresponds to the “branch number” of the table management table and column management table.As described for the table management table, “company (version)” corresponds to the data type of the table and table management table. The table ID is composed of “type” and “branch number.” When the data is read, the data management system automatically generates the row ID of the row management table to create a record for each row, and at the same time, the row ID. Are stored as item values in the row group and row ID fields of the value management table, respectively, in the value management table, and in the value management table, the table ID ( The company (version) + data type + hierarchy is automatically assigned to each row, so that the value management table can be identified by the row ID and the table ID. Each record can be specified.

  Next, as described with reference to FIG. 41, when the number of data items in the read record exceeds the value storage number (“value n”) in one line of the value management table, the data management system has, for example, a storage item value number of 30. In this case, in order to store the item values from the 31st item, a row for storing the item values is prepared in the row next to the row of the record, and the record is stored over two rows. Therefore, “serial number (cell sequence number)” is normally “1” (when the number of item values is 30 or less), but when the number of item values is 31 or more and the next row is prepared, “Serial number (cell sequence No.)” of the additional row is set to “2”. Then, a new cell (CELL) record is created and stored from the values of 31 or more data items. “Parent S (parent record sequence No.)” indicates the value of “serial number (sequence No.)” of the parent record (higher-level record) to which the storage record is subordinate. For example, in the case of the record in the first row (the value of “serial number (sequence No)” is “1”), since it is a file header record (FH), there is no parent record, and “parent S (parent record sequence) No) ”becomes“ 0 ”. In the case of the record on the second line (the value of “sequence number (sequence No)” is “2”), since it is a slip header record (DH), a file header record exists as a parent record, and “parent S ( "Parent record sequence No)" is "1" which is the value of the "serial number (sequence No)" of the parent record. Further, in the case of the record on the third line (the value of “sequence number (sequence number)” is “3”), since it is a slip detail line record (DD), the slip header of the slip to which the slip detail line belongs as a parent record A record exists, “parent S (parent record sequence No)” corresponds to “parent S (parent record sequence No)” in the row management table, and “FS (sequence number in same record)” corresponds to the row management table. To “FS (Sequence No. in Same Record)”. In “value 1” to “value n”, when data is read, each data item is identified in order according to the column definition of each data defined in the column management table, and each field value (data item) divided from the read record is specified. Value) is stored in the order of column IDs (in the order of “serial number” in the table ID).

  As shown in FIG. 29, the data management system according to the fifth embodiment also includes tables (volume table, volume management table, system management table, work management table) other than those described above. In addition, date and time information such as “valid date (self)” and “valid date (to)”, which are data items related to the date and time information of each table, are the data item values (company information and column management of the company management table). When the table column definition is updated, it can be used for version management.

Embodiment 6
FIG. 49 is a block diagram for explaining the concept when the data management system according to Embodiment 6 of the present invention is applied to a system development support CASE tool. FIG. 50 is a block diagram for explaining the concept of bidirectional data conversion between tables in the data management system according to the sixth embodiment of the present invention.
As shown in FIG. 49, the data management system according to the sixth embodiment uses the core architecture of the data exchange function of each of the above embodiments as the first data (for example, order data) and the second data profile of different data profiles. Data conversion between data (for example, user-specified data) (data and data exchange), and data conversion between data of a specific data profile and a screen display in a display format specified for the data ( Development of an engine that can be derived from data conversion (data input screen) and data conversion (data input form) between the data of a specific data profile and the form of the print format specified for the data And a CASE tool as a data management system according to the sixth embodiment. If the speed of the data management system becomes a problem, we will respond by adding a generation function. Specifically, as the system specifications of the data management system, the data conversion architecture in the first to fifth embodiments is the same as the data of the first data profile (for example, the ordering company data profile) stored in the column management table. This is an architecture that realizes bidirectional data conversion with data of a second data profile (for example, an ordering company data profile) stored in a table (data conversion between tables and tables). That is, as shown in FIG. 50, data conversion between tables is performed by using predetermined information (column ID, etc.) of definition information (record-related information created for each data item of the table) defined in the column management table. Is defined in the item relation definition table.

FIG. 51 shows the concept of one-way (one-way) data conversion between the table and the form of the data management system according to the sixth embodiment of the present invention. FIG. 51 (a) is a block for explaining the concept of data conversion. FIG. 4B is a block diagram showing a specific example 1, and FIG.
As shown in FIG. 51A, when data of a predetermined data profile (column definition) is converted to a corresponding form data profile (form form to form format) (table to form (one-way)), that is, a table As for the data conversion when converting the contents (data in a predetermined format) into the output image (form image), as shown in FIG. 51, the records defined in the column management table (created for each data item of the table) This is realized by defining related information in the item relation definition table. However, because various parameters (position, font, font size, color, etc.) for controlling the output image are required, a form profile item management (FORM_COLUMN (out)) table corresponding to the column management table items has been added. To do. Specifically, as shown in FIG. 51 (b), in the first specific example, a standard delivery note (TA1) “00020101-09” is obtained from the order (“20”) data of a certain company (company code “11199901”). Is output. Further, as shown in FIG. 51 (c), in the specific example 2, the PD label (unique) “49” of a certain company (company code “11199901”) is obtained from the scheduled arrival (packing) “40” data of the standard “00000001”. The data type “29” in the column management table in the above embodiment is defined in the column management table as a standard delivery note, but is a general form format TA1 and TA2. For example, in the profile column management table, the table ID identifier of the form TA1 is “00020101-09”, the table ID identifier of the form TA2 is “000201201-09”, etc. In the above embodiment, the data of the first data profile and the second data profile Although only data conversion (data exchange between tables and tables) is performed with the data, in this embodiment, field data conversion (data between a predetermined data profile and a form with a predetermined display format) is performed. In order to add (Data⇒Form), in the above embodiment, a table (form data profile) that manages various parameter values that control output directly described in the display program for such form output from the program. Management (FORM_COLUMN) table) is provided in the data management system of the present embodiment, because if this is not done, it is necessary to create a program each time a form to be output is generated.

FIG. 52 is a block diagram for explaining the concept of processing when the method of displaying the amount of money on the delivery slip is different in the data management system according to the sixth embodiment of the present invention.
Here, what should be noted when implementing this data management system is, for example, a method of displaying the amount of money on a delivery note. For example, “1000” as data means “thousand yen”, and the display method includes “1,000”, “¥ 1,000”, and “1000”. It is necessary to pay attention to the fact that is determined for each company. That is, as shown in FIG. 52, in the case where the data is “1000”, using the delivery note TA1, the data “1000” is “1,000” for the A company and “¥ 1,000” for the B company. In the case of company C, when the display method of “1000” is designated, it is necessary to change the display contents for each company. In this case, it is necessary to cope with the display method when exchanging data using the item relation definition table. For example, it is necessary to convert data of the table ID “11199901-20” (table storage data) into data of the table ID “00020101-09” (data in the form display format). That is, the parameter value of the output format of the form data profile management (FORM_COLUMN) table is not stored in the form data profile management table, but is treated as a simple output area, and “000,000,000”, “####” Parameter values such as “##, ## 0” and “¥ ####, ## 0, ## 0” are realized by a column management table or an item relation definition table. The PD label issuing function is also realized by using the conversion function. In this case, it is necessary to add a barcode creation function to the function management table.

FIG. 53 shows the concept of bidirectional data conversion between the table and the display screen of the data management system according to the sixth embodiment of the present invention, (a) is a block diagram for explaining the concept of data conversion, b) is a block diagram showing a specific example 1, and (c) is a partial block diagram showing a specific example 2.
As for data conversion when converting table contents and input / output data of the display screen, this data management system is defined in the column management table (created for each item of the table) as shown in FIG. This is realized by defining record related information in the item related definition table. However, in this case, since various parameters (position, font, font size, color, in / out classification, etc.) for controlling the input / output data of the display screen are required, the screen corresponding to the column management table items on a one-to-one basis. A display profile item management (Form_Column) table (same configuration as the above-mentioned form data profile management) is added. Specific example 1 uses the displayed customer order edit screen (identifier “0009010-01-01”, and registers / changes / changes the order (“20”) data of a certain company (company code “11199901”) from the input data. Specific example 2 uses the displayed inventory management screen (identifier “010040101-01”) to register / change / delete inventory data, and from the screen, the inventory list form Note that, for the table ID identifier (table ID), the identifier of the table ID in the current column management table is: company code (6 digits) + version information (2 digits) + data type (2 digits) (For example, “11199990120”, “0000000130”, etc.), the data storage area of the output image and the input / output data rating corresponding to the screen For even naming rules table ID identifier of frequency, be as predetermined rule defined similarly.

FIG. 54 is an explanatory diagram schematically showing a column management table used in the data management system according to the sixth embodiment of the present invention. FIG. 55 is an explanatory diagram schematically showing a form profile item management (FORM_COLUMN) table used in the data management system according to the sixth embodiment of the present invention. FIG. 56 is an explanatory diagram schematically showing a form (FORM) table used in the data management system according to the sixth embodiment of the present invention.
As shown in FIG. 54, the column management table has the same configuration as in each of the above embodiments. As shown in FIG. 55, the form profile item management (FORM_COLUMN) table has items corresponding to the column management table on a one-to-one basis. Specifically, the form column management table includes, as its data items (columns), “form ID (FORM_ID)”, “column ID (COLUMN_ID)”, “column name (COLUMN_NAME)”, “left end position (LEFT)”, “Top position (TOP)”, “Width (WIDTH)”, “Height (HEIGHT)”, and “Font size (FONT_SIZE)”. There is a one-to-one correspondence between “form ID (FORM_ID)” and “column ID (COLUMN_ID)”. In “Left end position (LEFT)”, “Upper end position (TOP)”, “Width (WIDTH)”, “Height (HEIGHT)”, and “Font size (FONT_SIZE)”, item values of data items to be printed on the form The left end position, upper end position, width, height, and font size of each are stored. The form profile item management (FORM_COLUMN) table creates a record for each form. The form ID (FORM_ID) can have the same naming rule as the table ID. Therefore, the form ID (FORM_ID) may be unnecessary. In addition, a table ID code is also specified in the specification column for the format of each company's invoice or PD label stored in the company-specific data profile (EXCHANGE_DATA) table. Therefore, the index and key items of the form profile item management (FORM_COLUMN) table need not be the same as those of the profile item management (COLUMN) table. As shown in FIG. 56, the form image is stored as the value of the data item “image file (IMAGE_FILE)” of the form (FORM) table corresponding to the “form ID (FORM_ID)”. The width and height are also stored as values of “width (WIDTH)” and “height (HEIGHT)”.

FIG. 57 is an explanatory diagram schematically showing a setting example of a column management table used in the data management system according to the sixth embodiment of the present invention. FIG. 58 is an explanatory diagram schematically showing a setting example of a screen display profile item management (Form_Column) table used in the data management system according to the sixth embodiment of the present invention. FIG. 59 is an explanatory diagram schematically showing a setting example of a screen display (Form) table used in the data management system according to the sixth embodiment of the present invention. FIG. 60 is a block diagram illustrating a setting example of a screen display profile item management (Form_Column) table used in the data management system according to the sixth embodiment of the present invention.
As shown in FIG. 57, the column management table has the same configuration as in the above embodiments. As shown in FIG. 77, the screen display profile item management (Form_COLUMN) table (same configuration as the form profile item management table) has items corresponding to the column management table on a one-to-one basis. Specifically, the screen display column management table includes “form ID (FORM_ID)”, “column ID (COLUMN_ID)”, “column name (COLUMN_NAME)”, and “left end position (LEFT)” as data items (columns). , “Top position (TOP)”, “width (WIDTH)”, “height (HEIGHT)”, and “font size (FONT_SIZE)”. There is a one-to-one correspondence between “form ID (FORM_ID)” and “column ID (COLUMN_ID)”. “Left end position (LEFT)”, “Upper end position (TOP)”, “Width (WIDTH)”, “Height (HEIGHT)”, and “Font size (FONT_SIZE)” are items of data items to be displayed on the display screen. The left end position, upper end position, width, height, and font size of the value are stored. The screen display profile item management (FORM_COLUMN) table creates a record for each screen display unit. The form ID (FORM_ID) can have the same naming rule as the table ID. Therefore, the form ID (FORM_ID) may be unnecessary. In addition, a table ID code is also specified in the specification column for the format of each company's invoice or PD label stored in the company-specific data profile (EXCHANGE_DATA) table. Therefore, the index and key items of the screen display profile item management (FORM_COLUMN) table need not be the same as those of the profile item management (COLUMN) table. As shown in FIG. 58, the screen display image is stored as the value of the data item “image file (IMAGE_FILE)” of the screen display (FORM) table corresponding to the “form ID (FORM_ID)”. The width and height are also stored as values of “width (WIDTH)” and “height (HEIGHT)”. As shown in FIG. 60, the data management system stores the definition (column definition) regarding the core data in the table in the profile column management table, and the definition (form definition) regarding the display data in the screen display profile column management table. Further, the conversion contents between the display data and the core data are defined in the item relation definition table. Then, the data item of the column ID of the column management table is associated with the form ID of the data item of the specific screen display one-to-one via the link information (data related information) of the item related definition table, and the core data and Data conversion with display data is performed. The display data converted in this way is displayed according to the display definition (form definition) stored in the screen display table.

Here, bidirectional data conversion is performed between the screen display table and the screen display column management table so that, for example, customer input can be handled. Specifically, for example, it is assumed that the designated delivery form of a predetermined ordering company is a chain store association unified slip (TA1). In this case, input / output specifications are described from each item (screen item: [related data item]) numbered (1) to (21) below. The input items are items of the following numbers (1) to (3) and (23), (26) and (29). In addition, since the items of the following numbers (21), (22), (24), (25), and (27) can be derived from the product master or past data, it is preferable to obtain them when inputting key items. .
Voucher header (1) Column A: [Payment terms] ⇒ Enter code (Select from COLUMN_VALUE value)
(2) Column B: [Number of divisions] => Numeric input check, number of digits 1
(3) Column D: [Route code] ⇒ Text input, format check (*** TA99 **)
(4) Correction category: [correction presence / absence] ⇒ <Not used for customer order input? >
(5) Actual delivery date: [shipment date] ⇒ date input check (6) Company name: [ordering company name] ⇒ default display “digital”
(7) Business partner name: [name of the contracting company] ⇒ default display “Yamada Sangyo”
(8) Store name: [Ordered store name] ⇒ Text input, number of digits, half-width katakana check (9) Company / Store code: [Store code] ⇒ Numerical value check
(10) Classification code: [Department code] ⇒ Enter code (Select from COLUMN_VALUE value)
(11) slip classification: [slip classification] ⇒ code input (select from COLUMN_VALUE value)
(12) Voucher number: [Voucher No] ⇒Numeric input check, 8 digits
(13) Supplier code: [Supplier code] ⇒ Default display (EXCHANGE table stored value)
(14) Order Date: [Order Date] ⇒ Date Input Check (15) Delivery Date: [Delivery Designation Date] ⇒ Date Input Check (16) Total Quantity: [Total Order Quantity] ⇒ Calculation Display (Total Item Quantity)
(17) Total Cost Amount: [Total Cost Amount] ⇒Calculation Display (Total Cost Amount)
(18) Total selling price: [Total selling price] ⇒Calculation display (Total selling price)
(19) Column F: [island number (-) machine number] ⇒ text input, format check (99-9999)
(20) Column L: [(Contents of customer's order summary etc.)] ⇒ <* Enter as appropriate at the contracting company> slip details x 6
(21) Product name: [Product name] ⇒ Text input, number of digits, half-width katakana check (22) Standard: [Standard] ⇒ Text input, number of digits, half-width katakana check (23) Product code: [JAN code] ⇒ Numerical input check , Number of digits 13
(24) Input number: [Input number] => Check numeric input, number of digits 3
(25) Case: [Case] => Numeric input check, 3 digits
(26) Quantity: [Order quantity] ⇒ Numerical input check, 4 digits
(27) Original unit price: [Unit price] => Numeric input check, 7 digits
(28) Cost Amount: [Cost Amount] ⇒Calculation Display (Quantity x Original Unit Price)
(29) Unit price: [Unit price] ⇒ Check numeric input, 7 digits
(30) Sales price: [Selling price] ⇒ Calculation display (quantity x sales price is calculated)
The item indicated by the underline (broken line) of the item in the detail line can be derived from the past data, so it is desirable that the item can be corrected after being derived. Functions such as issuance of invoices, issuance of shipping instructions, customer order entry, and shipping quantity correction can be handled by the above program.

Data management system processing (Embodiments 2 to 6)
FIG. 61 is a flowchart showing the ordering company data reading / storing process of the data management system according to the second to sixth embodiments of the present invention.
As shown in FIG. 61, in the ordering company data reading / storing process, first, in STEP 11, it is determined from which company (for example, ordering data) the data received from the file name or the storage location of the received data, and data exchange is performed. Check the availability. Next, in STEP 12, based on CONTROL_INI (control information) of the table management table, the read data is divided into records while being sequentially analyzed. Next, in STEP 13, a table ID consisting of the ordering company code (+ version NO) + data type + branch number is specified. Next, in STEP 14, based on the identified table ID, the column management table is referred to, and the data item sequence No. Divide each data item value of each read record according to (serial number). Next, in STEP 15, a row group (ROW_GROUP) and a row ID (ROW_ID = ROW_GROUP + ROW_ID_SEQ) are issued based on a predetermined rule. Next, in STEP 16, the identifier value, the matching item value, and the basic item value (slip No., order date, etc.) are extracted from the data item value of each read record and stored in the row management table together with the row ID, table ID, etc. Store. Next, in STEP 17, all data item values (divided) of each read record are sequentially stored in each row of the value management table together with the table ID and the like, and only the original data (primary data) received from the ordering company is created and processed. Exit.

FIG. 62 is a flowchart showing the slip list display process of the data management system according to the second to sixth embodiments of the present invention.
As shown in FIG. 62, in the slip list display process, when a search condition is input in STEP 51, the search condition is determined in STEP 52. If the display type is “by data type” in STEP 61, the corresponding record in the row management table is read in STEP 62, and the slips by data type are displayed in a list in STEP 63, and the process is terminated. If the display type is “by ordering company” in STEP 71, the corresponding record in the row management table is read in STEP 72, and the slips by ordering company are displayed in a list in STEP 73, and the process ends. If the display type is classified by date range in STEP 81, the corresponding record of the row management table is read in STEP 82, the slips by date range are displayed in a list in STEP 83, and the process is terminated.

FIG. 63 is a flowchart showing slip detail display processing of the data management system according to Embodiments 2 to 6 of the present invention.
As shown in FIG. 63, in the slip detail display process, when the selection and display designation of the slip is performed in STEP 101, the designated content is determined in STEP 102. If the designated content is the ordering company original data in STEP 110, the order is placed in STEP 111. The column management table is searched with the table ID of the company original data. Then, the module of STEP 112 refers to the column management table, acquires each value from the value management table in the order of the data items, and sets and displays the acquired values in the order of the data items in STEP 113. If the specified content is the ordering company slip data in STEP 120, the column management table is searched with the table ID of the ordering company slip data in STEP 121, and each value is set in the order of the data items by referring to the column management table in the STEP 122 module. Obtained from the management table, and in STEP 123, the obtained values are set and displayed in the order of data items. If the specified content is system standard data in STEP 130, the column management table is searched with the table ID of the system standard data in STEP 131, the column management table is referred to in the module of STEP 132, and the value management table stores each value in the order of the data items. In step 133, the acquired values are set and displayed in the order of data items. In STEP 140, if the specified content is the order receiving company specifying data, the column management table is searched with the table ID of the order receiving company specifying data in STEP 141, the column management table is referred to in the STEP 142 module, and each value is set in the order of the data items. Obtained from the management table, and in STEP143, the obtained values are set and displayed in the order of data items.

FIG. 64 is a flowchart showing the ordering company original data acquisition process in the slip detail display process of the data management system according to the second to sixth embodiments of the present invention.
As shown in FIG. 64, in the ordering company original data acquisition process, in STEP 112A, the value management table is searched with the table ID of the ordering company original data, and the record group storing the data item value in the same record is determined. Next, in STEP 112B, the item value of each record stored in the order of the data items in the column management table is acquired.

FIG. 65 is a flowchart showing the ordering company slip data acquisition process in the slip detail display process of the data management system according to the second to sixth embodiments of the present invention.
As shown in FIG. 65, in the ordering company slip data acquisition process, in STEP 122A, the value management table is searched with the table ID of the ordering company slip data, and the data item value storage record group in the same record is determined. Next, in STEP 122B, the item value of each record stored in the order of the data items in the column management table is acquired. Next, in STEP 122C, the item relation definition table is referred to, and the original data item information related to each item is obtained in the order of the ordering company slip data. At this time, using the trigger column ID as a key, the trigger column ID (for original data) storing the display item value is searched and acquired via the corresponding target column ID. Next, in STEP 112D, based on the item-related information, the corresponding original data item value is substituted for each data item of the ordering company slip data.

FIG. 66 is a flowchart showing system standard data acquisition processing in slip details display processing of the data management system according to Embodiments 2 to 6 of the present invention.
As shown in FIG. 66, in the system standard data acquisition process, in STEP 132A, the value management table is searched with the table ID of the system standard data, and the data item value storage record group in the same record is determined. Next, in STEP 132B, the item value of each record stored in the order of the data items in the column management table is acquired. Next, in STEP 132C, the item relation definition table is referred to, and the original data item information related to each item is obtained in the order of items of the system standard data. At this time, using the trigger column ID (for standard data) as a key, the trigger column ID (for original data) storing the display item value is searched and acquired via the corresponding target column ID. In STEP 132D, the item value of the corresponding original data is substituted for each item of the system standard data based on the item related information.

FIG. 67 is a flow chart showing order-receiving company designation data acquisition processing in slip details display processing of the data management system according to Embodiments 2 to 6 of the present invention.
As shown in FIG. 67, in the order receiving company designation data acquisition process, in STEP 142A, the value management table is searched with the table ID of the order receiving company designation data, and the data item value storage record group in the same record is determined. Next, in STEP 142B, the item value of each record stored in the order of the data items in the column management table is acquired. Next, in STEP 142C, the item relation definition table is referred to, and the original data item information related to each item is acquired in the order of items of the order receiving company designation data. At this time, using the trigger column ID (for designated data) as a key, the trigger column ID (for original data) storing the display item value is searched and acquired via the corresponding target column ID. Then, in STEP 142D, based on the item-related information, the item value of the corresponding original data is substituted for each item of the order receiving company designation data.

FIG. 68 is a flowchart showing data output processing of the data management system according to Embodiments 2 to 6 of the present invention.
As shown in FIG. 68, in the data output process, when an output designation is made in STEP 151, the designated content is judged in STEP 152. If the specified content is the ordering company slip data in STEP160, the column management table is searched with the table ID of the ordering company slip data in STEP161, the column management table is referenced in the module of STEP162, and each value is entered in the order of the data items. Obtained from the management table, and in STEP 163, the obtained value is stored in the ordering company slip data storage means. If the specified content is system standard data in STEP 170, the column management table is searched with the table ID of the system standard data in STEP 171. The column management table is referred to in the STEP 172 module, and each value is stored in the row management table in the order of the data items. In STEP 173, the acquired value is stored in the system standard data storage means. In STEP 180, if the specified content is the order receiving company specifying data, the column management table is searched with the table ID of the order receiving company specifying data in STEP 181, and the column management table is referred to in the STEP 182 module, and each value is entered in the order of the data items. Obtained from the management table, and in STEP 183, the obtained value is stored in the order receiving company designation data storage means. The modules of STEPs 162, 172, and 182 are the same as the modules of STEPs 122, 132, and 142.

FIG. 69 is a flowchart showing item value conversion processing of the data management system according to Embodiments 2 to 6 of the present invention.
As shown in FIG. 69, in the item value conversion process, when the ordering company data is read in STEP 201, in STEP 210, 220, 230, 240, 250, 260, item name verification, item content verification, attribute verification, display method verification are performed. , Digit verification, and domain value verification are performed. In STEP 210, the item name is verified. If it is determined in STEP 211 that it is a synonym, an association definition is made in STEP 212. If the item content is verified in STEP 220 and it is determined in STEP 221 that the object name is the same name, the relationship is undefined in STEP 222. If the attribute (data type) is verified in STEP 230 and it is determined in STEP 231 that there is a related definition, the attribute is converted in STEP 212 based on the related definition. In STEP 240, the display method is verified. If it is determined in STEP 241 that there is a change option, the display method is changed in STEP 242. If the number of digits is verified in STEP 250 and it is determined in STEP 251 that there is a digit loss, a warning display / correction process is performed in STEP 252. In STEP 260, the domain value is verified. In STEP 261, if it is determined that there is code substitution, in STEP 262, code semantic conversion is performed. Details of these item value conversions are as described above.

FIG. 70 is a block diagram illustrating features of data conversion processing and display processing of the data management system according to Embodiments 1 to 6 of the present invention. FIG. 71 is a block diagram for explaining display processing of data conversion processing of a conventional data management system for comparison with FIG.
As shown in FIG. 71, a conventional order management system 600 as a data management system includes ordering data having a data profile unique to each business partner (ordering company) such as Company A, Company B, Company C,. (Actual data) is column-defined (relation schema design) for each ordering company, and ordering data tables 611, 612, 613,... Are created. Then, the actual data of the order data tables 611, 612, 613,... Is generated by the display programs 621, 622, 623,... Created for the order data tables 611, 612, 613,. Display on screen 1. Further, the conventional order receiving / order management system 600 uses the conversion program (PG) created for each order data table 611, 612, 613,... From each order data table 611, 612, 613. User order data 614 is created. Then, the actual data of the user order data table 614 is displayed on the screen 1 by the display program 624 created for the user order data 614.

  On the other hand, as shown in FIG. 70, the data management system according to the first to sixth embodiments is basically configured with order data (actual data) of each company such as A company, B company, and C company as described above. In addition, all of the values 1 to n are stored in the value management table 213 as the transaction data system together with the row ID and the table ID (or table ID). In addition, a row ID, a table ID, an identifier, a match value, and the like as an index of each record are stored in the row management table 212. Further, only one common display program 26 for displaying the actual data of each company in the various display formats described above is prepared. For example, when the real data of company A and the real data of company B are displayed on the screen 1 in the user-specified format via the display program 26, as the conversion processing by the master data system, the company A and B of the column management table 211 are used. The company's data item definition (column definition) is referred to, and the item relation definition in the item relation definition table 217 is referenced to obtain link information between the user's column definition and the column definitions of the A company and B company, Through such link information, the actual data of company A and company B is displayed on screen 1 in a display format in a format specified by the user company.

  Specifically, for example, the item value of the order data record (row ID “R1”) of company A is the row ID “R1” of the row management table 212 and the column ID of the column management table 211 in the value management table 213. It is stored as actual data in each row specified by “C11, C12, C13, C14”. The display program 26 acquires the actual data (data for four lines of the value management table 213) and displays it on the screen 1 in a predetermined format as A company order (actual) data. The same applies to the ordering data of Company B and Company C. Further, when displaying the order data of the company A in the standard format, the column ID corresponding to the data item of the order data in the company A format in the item relation definition table 217 is set as the trigger column ID, and the value of the data item is the order of the standard format. Set to the data item of the target column ID of the data. Then, the display program 26 acquires the item value (actual data) of the order data of the company A set in the data item of the order data of the standard format, and displays it on the screen 1 as the company A order (standard format) data. On the contrary, when the B company order data (actual data) is displayed in the user specified format data via the standard format, the column ID corresponding to the data item of the order data in the B company format in the item relation definition table 217 is triggered. As the column ID, the value of the data item is set in the data item of the target column ID of the order data in the standard format. Next, using the column ID of the order data in the standard format as the trigger column ID, the value of the data item is set in the data item of the target column ID of the order data in the user-specified format. Then, the display program 26 acquires the item value (actual data) of the order data of Company B set in the data item of the order data in the user-specified format via the standard format, and displays the screen as user order (user format) data. 1 is displayed.

Embodiment 7
FIG. 72 is an explanatory diagram showing a column management table of the data management system according to the seventh embodiment of the present invention.
As shown in FIG. 72, the data management system according to the seventh embodiment handles, as management target data, receipt computer data (reckon data) used in a medical institution, and has many data profiles (column definitions). In addition to defining the column data of the medical institution (A, B...) In the column management table, data conversion is performed via the standard data profile (standard receptacle) in the same manner as described above. The column management table in FIG. 72 is the same as the column management table in the above embodiment. Specifically, the column management table has the same data items as the column management table. On the other hand, “table ID” of the column management table stores data that uniquely indicates the table type of the receptacle. In FIG. 72, for convenience of explanation, a character string such as “Standard Reckon” is stored, but actually, a code uniquely indicating each table is stored. In addition, in the data item name (item name) of the column management table, the item names of the data items of each table (standard receptacle table etc.) are stored in order corresponding to the column ID. Other data items such as column ID, company ID, branch number, serial number, and the like are the same as the column ID, company ID, branch number, serial number, and the like in the column management table of each of the above embodiments.

Embodiment 8
FIG. 73 is an explanatory diagram showing a function management table of the data management system according to the eighth embodiment of the present invention.
As shown in FIG. 73, in the function management table (first specific example), function contents, parameters, and storage locations that were conventionally defined in the program are taken out from the program and stored as item values thereof. In addition to operations such as addition and subtraction, arbitrary calculation processing can be defined in the table and executed. Thereby, according to the function table according to the eighth embodiment, as described in the above-described embodiment, it is possible to prepare for the addition, deletion, and change of the program. The function management table has, as data items, “function ID”, “function name”, “function contents”, “parameter 1”, “parameter 2”, “parameter 3”. Yes. “Function ID” is a code uniquely assigned to each function. “Function name” indicates the name of each function (addition, subtraction, etc.). “Function content” indicates the content (processing procedure) of each function (for example, A + B in the case of addition). Parameters such as “parameter 1”, “parameter 2”, “parameter 3”, etc. are used as parameters in the processing (calculation etc.) of the corresponding function content, and the necessary parameters are set to these parameters 1, 2, 3,. Store it in. “Storage location” indicates a storage area for storing the return value of the corresponding function.

Embodiment 9
FIG. 74 is an explanatory diagram showing a function table of the data management system according to the ninth embodiment of the present invention.
As shown in FIG. 74, the function table (second specific example) is similar to the above-described embodiment, in which function contents and inputs and outputs conventionally defined in the program are taken out from the program, It is stored as the item value, and as described in the above embodiment, it is possible to prepare for the addition, deletion, and change of the program. The function table has “function ID”, “output”, “function”, “input”, and the like as data items. “Function ID” is a code uniquely assigned to each function. “Output” indicates the output of each function. “Function” indicates the content (processing procedure) of each function (for example, * 2 in the case of F1). “Input” indicates an input of each function. For example, the function “F1” in FIG. 74 indicates a function that outputs a value obtained by doubling (* 2) the input A as the output C.

Embodiment 10
FIG. 75 is an explanatory diagram showing an index management table of the data management system according to the tenth embodiment of the present invention. FIG. 76 is an explanatory diagram showing a row relation management table of the data management system according to the tenth embodiment of the present invention.
The index management (INDEX) table shown in FIG. 75 is for managing the matching values in the row management table of each of the embodiments described above. The index management table has “ID”, “row ID”, “object ID”, “column ID”, “value”, and “content” as data items. The “ID” is automatically issued corresponding to an index or a search key (for example, a match value) used in the row management table. “Row ID” corresponds to the row ID of the row management table. “Object ID” corresponds to the object ID of the target management table. “Column ID” corresponds to the column ID of the column management table. “Value” indicates the value (data item value) of the corresponding object ID. “Content” indicates the content (data item name) of the value of the corresponding object ID. The “column ID” and “content” may be omitted. In this way, at least the row ID, the object ID, and the value are stored in the index management table and stored, so that they are more flexible than the case where the index is managed by storing them in the column management table or the row management table. Data management can be performed. For example, when adding, deleting, or changing an index, it is only necessary to add, delete, or change a record in the index management table, and maintenance becomes easy. The method of using the index stored in the index management table is the same as that described in the description of the matching process between the ordering data and the shipping schedule data, and the necessary items in the search process such as the matching process. Values are extracted from the index management table as needed.

  The row-related management (ROW_CHAIN) table shown in FIG. 76 manages the branch numbers in the column management table etc. in the above embodiments. The row relation management table has “ID”, “row ID”, “parent row ID”, “number of parents”, “relevant value”, and “content” as data items. “ID” is automatically issued corresponding to a relationship such as a parent-child relationship or a hierarchical structure between records stored in the row management table. “Row ID” corresponds to the row ID of the row management table. “Parent row ID” indicates a row ID of a record (or table) serving as a parent when a record (or table) serving as a parent exists in the record (or table) corresponding to the row ID. “Number of parents” indicates the number of records (or tables) serving as a parent when there is a record (or table) serving as a parent in the record (or table) of the corresponding row ID. “Related value” indicates the value of the identifier of the record of the corresponding parent row ID. “Content” indicates the content (record name, table name, etc.) of the record of the corresponding row ID. The “related value” and “content” may be omitted. In this way, at least the row ID, the parent row ID, and the number of parents are stored in the row management table so that they are stored in the column management table and the record related information such as the parent-child relationship and the hierarchical structure. Data management can be performed more flexibly than in the case of managing. For example, when adding, deleting, or changing record-related information, all that is required is to add, delete, and change records in the row-related management table, and maintenance becomes easy. Further, as shown in the lower side of the table of FIG. 76, the row relation management table not only enables management of records having a hierarchical structure such as ordering data (in the case of one parent) but also a certain record ( Alternatively, management in the case where the table) has a plurality of parents is also possible.

  For example, in the case of ordering data composed of hierarchical records, a slip header with a row ID “SYS002” is linked or subordinate to the lower order of the file header with the row ID “SYS001”, and lower than the slip header with the row ID “SYS002”. The slip details (1 to 5) of the row IDs “SYS003 to SYS007” are linked or subordinate. Further, since there is no parent record in the file header of the row ID “SYS001”, the number of parents is “0”. On the other hand, since the slip header of the row ID “SYS002” has a file header (SYS001) as a parent record, the number of parents is “1”. Furthermore, since the slip details of the row IDs “SYS003 to SYS007” have a slip header (SYS002) as a parent record, the number of parents is “1”. On the other hand, a case where a record or table having a plurality of parents is managed will be described. For example, a customer unit price master table (SYS 903) has two customers, a customer master table (SYS 901) and a product master table (SYS 902). Therefore, the row ID (SYS903) of the customer unit price master table is stored over two rows of the row related management table (ID = 4752 and 4753), and the row ID (SYS901) of the customer master table is added to the parent row ID of each row ID. The row ID (SYS 902) of the product master table is stored. The row ID (SYS 903) of the customer unit price master table stores “2” in the parent number. As a result, only by referring to the row relation management table, it is possible to acquire record related information of a parent-child relationship or a hierarchical relationship of a specific record stored in the row management table, and the editing thereof is facilitated.

The main features of the data management system according to the present invention described in detail above are summarized below.
Feature 1: A basic physical data structure consisting of only three physical tables: a column management table, a row management table, and a value management table. As a result, regardless of the number of tables (physical tables) of the conventional physical data structure, all the data (item contents and item values) are stored in three physical tables (column management table, row management table and value management table). Can be stored and managed.
1) The column management table is a table that defines and manages columns (attributes of each domain) of a conventional table. The column management table defines the data format (profile) of various conventional data (for example, product master data, customer master data, customer unit price master data, inventory master data, order data, etc. shown in FIGS. 4 to 8). . That is, the column management table defines design information (relation schema) of a conventional data container (physical table) for storing these data. Specifically, the column management table stores the column name (data item name) of the column (also referred to as data item or attribute) of the conventional physical table, which is design information (relation schema) of the data container (physical table). To do. Also, a unique column ID is assigned to each column name in the column management table. Furthermore, in addition to the column ID, other information for defining the data item such as the data type, position, and length of the data item is associated with each data item of the management target record defined in the column management table. It may be stored. Note that the attribute information (attribute name, data type, length, etc.) of each data item of the conventional physical table is uniquely identified and acquired by the column ID. The data stored in the column management table is master data. In addition, the column names and the like of the conventional physical table (for example, “product name” and “product ID” in the case of the product master table) are not the column (data item) of the column management table of the present invention, but the data item value. Stored and defined as (value of each attribute). In the column (data item) of the column management table, a general name (“item name”, “column ID”, “data type”, etc.) for identifying a conventional column (data item) stored as a data item value is stored. Is defined. In addition, for example, in the conventional product master table, “product ID”, “product name”, “unit price”, etc. are defined as columns (data items) in a predetermined order (predetermined arrangement), and corresponding to these columns , “001”, “cigarette”, “200 yen”, and the like are stored as data item values (field values) in each record. On the other hand, the column management table of the present invention has the attribute of each field that defines the format of the conventional product master table as a data item value of a column (“column ID”, “column name”, etc.). Product ID ”,“ Product Name ”, etc.) are stored.
2) The row management table is basically a table for storing index information. When specific data is read and stored, each record of read (input) data (data in a row unit of a conventional physical table) is stored. A row ID is assigned as an index for uniquely identifying each row in the order of reading, and the row ID is stored in the row management table in that order. The data stored in the row management table is transaction data. Also, for example, when reading product master data that defines “product ID”, “product name”, “unit price”, etc. as columns, in a predetermined order (predetermined arrangement), “ Each time 001, “cigarette”, “200 yen” (first record), “002”, “chocolate”, “100 yen” (second record), etc. are read, row IDs are automatically assigned in order. Generated and stored in the row management table (“R01”, “R02”..., Etc.).
3) The value management table is a table for storing data item values (also referred to as domain values). When reading and storing specific data, each record of read (input) data (in units of rows of a conventional physical table) Each time (data) is read, the value of each field constituting the record is stored in association with the row ID. At this time, the column management table is referred to according to the type (data name, table name, etc.) of the read record, and the table ID of the record of the corresponding type is determined and extracted. Thereby, the data item name corresponds to the value by the table ID. Alternatively, all the values (data item values) of the fields constituting the record are stored in one line of the value management table. At this time, referring to the column management table according to the type of the read record (data name, table name, etc.), the table ID of the record of the corresponding type is determined and extracted, and the order of the data item names of the table ID Store the value with. As a result, it is stored as a series of data (values) in the cells of the corresponding row. Each row is identified by a row ID, and each value is specified by a row ID and a column ID. The data stored in the value management table is transaction data. Further, each value (value of each field) of the data item is stored in a place (each field) uniquely determined by the column ID and the row ID. Further, when each record is read, the cell is identified by the row ID of the row table automatically given to the record and the column ID of the column table for identifying the design information (data item attribute information) of the record ( Specify the column and row) and store the value of the data item in the specified cell.

Feature 2: Dynamically change data item contents (schema) according to business contents 1) Definition of all managed data (known data) handled in column management table (definition of conventional physical structure table) Stored as a data item value. That is, the physical structure (format definition) of all data is stored and defined in order in one column management table. Also, by changing only the column management table, the item contents can be changed dynamically. In addition, the physical structure of data and business contents can be managed separately.
2) When the physical structure (format definition) of any data is changed (for example, adding / deleting / modifying items), the normal data editing operation of adding / deleting / changing data item values in the column management table The physical structure of the data can be reflected in the column management table to change the physical structure of the data.
3) Conventionally, the container itself is created according to the business. Therefore, a plurality of (many) tables having different schemas or physical data structures (data formats) corresponding to the number of business contents are required according to the business contents. That is, each of the conventional tables has a schema reflecting business contents. For this reason, the data items of the columns of each table are fixed by the schema, and special processing for correction is required for correction (addition / deletion / editing) of the data items (for example, in the case of commercially available database software, the table (Addition, deletion, and editing of each data item in the column are handled by the program behind the scenes).
4) In the present invention, all information (column information, row information, and cell values) of data to be handled is divided and stored in the above three tables (column table, row table, value management table). That is, the physical data structure (attribute information of column data items) of all tables is stored in the column table as data item values (master data), identified by column ID, and the index of the read record is stored in the row table as row ID. And each data item value of the read record is stored in a cell of the value management table determined by the column ID and the row ID. Therefore, the business rules need not be reflected in the physical structure (physical data structure) of the data.
5) That is, the physical structure of the table for storing data (design information of the container) is stored and defined as a data item value in the column management table. Therefore, no matter what the business is, always process all data (store, retrieve, process, output, display, etc.) with three physical structure tables (column table, row table, value management table) can do.
6) For example, the format of three tables of a customer table, a unit price table, and a customer sales unit price table is stored and defined in one column management table. The row ID of the row management table is incremented for each record input, and the data item value corresponding to the column ID and the row ID is input to the cell. Using this column management table, row management table, and value management table, a customer sales unit price program can be easily realized.
7) Conventionally, data is statically defined (physical structure tables corresponding to business are defined and designed, and data items are statically defined in the design contents). That is, the data item content is fixed as a table column when the table is created, and cannot be easily changed. To change, it is necessary to redefine the table to add / delete / modify attributes directly. Therefore, if the physical table is modified (addition / deletion / content change), the table structure (definition) itself of the physical table will change. Therefore, modify the display program for the physical table to display the modified data. It was necessary to display on the screen.
8) The present invention can be reflected by correcting (adding / deleting / changing) item values in the column management table even when adding / deleting / changing items. In other words, it is not necessary to modify the item contents of the column management table (the physical structure / definition of the table is not changed). The physical structure of the column management table is always the same (same) as any conventional physical table. Therefore, the display program can be changed dynamically. Specifically, the program can be changed by changing the data of the table by setting the table out of the program. Further, items specialized for business are entered as item values, not as attributes of the column management table. Adding, deleting, and changing item values is easier than changing definitions.
9) The first rank bottom part (program part) can be executed with data. Specifically, the program can be changed by changing the data of the table by setting the table out of the program.

Feature 3: Configuration of column management table 1) A table ID is assigned in one-to-one correspondence with the data format (column definition) of the read record, and a serial number (sequence NO) is assigned in the order of the columns in the same data format. Allocate and associate one-to-one with the fields of the read record.
2) Alternatively, column IDs are assigned in a one-to-one correspondence with the order of the fields of the read record in the specific data format. In this case, the column ID has a one-to-one correspondence with the table ID + sequential number (sequence NO). Here, the column ID can be a code system in which a code (number) composed of a combination of a table ID (company code + version code + hierarchy code) and a serial number (sequence NO) is simplified.

Feature 4: Separate management of column management table (separate location on the net) & one view 1) Only the column management table can be managed separately (because it handles master data). In other words, the column management table is stored in the management center system (server) to manage the profile information (update, etc.), and the column management table is not placed in the user side system (client), but the management target data is read and row management is performed Only the program for creating the table and the value management table is provided, and the row management table and the value management table are created by referring to the column management table of the management center system via the network.
2) Alternatively, whenever the column management table (latest version) managed by the management center system is updated (upgraded), it is downloaded to the user's system and the row management table and value management are referenced by referring to the column management table. Try to create a table.
3) Thus, according to the present invention, three tables can be stored separately (on another PC). For example, it can be distributed and stored on the network.
5) By managing only the column management table (company profile) on the network, the user can use the latest table definition. For example, the company profile on the net may be viewed remotely or copied. On the other hand, the administrator can edit and manage the company profile at another location and distribute it according to the user's request.
6) Even if it is managed in another place, it can be shown as one view by connecting with a network.
7) If the network is connected without load as the distribution infrastructure, you can go directly to the network instead of copying. However, in the case of the Internet, there is a traffic problem. .

Feature 5: Supports data hierarchization 1) Record sub-ID is defined and stored in the column management table. That is, when the management target data is composed of records having a hierarchical structure, a hierarchical code (record sub ID) corresponding to the hierarchical structure is added to the table ID. That is, the hierarchical structure is managed by the record sub IDs that are continuous with the table ID. This makes it possible to deal with management target data having a hierarchical structure in the record. Also, by adding a record ID to the table ID, the table ID within the same data type (for example, order data consisting of three layers of file header, slip header, and slip details) is uniquely identified (the table ID is a file header record). , Whether it belongs to a slip header record or a slip detail record). In addition, the hierarchical structure can be dealt with by securing a parent-child relationship between data stored in the column management table. Also, when dropping data into the row management table, the parent-child relationship can be secured by looking at the column management table.
2) Many tables have a hierarchical structure, but this management system can simplify the system configuration.

Feature 6: Version management of column definition (in the column management table) 1) A company code assigned to each company to which the management target data of a specific data format belongs, and a version code indicating the version of the data format of the company It consists of. This makes it possible to manage the version of the data format by referring to the version code of the table ID.
2) Define the date and time information such as profile usage period or effective date (self) / effective date (to) in the column management table, and refer to the value of the data item when converting the data, and use the version column Refer to the definition.
3) When the data conversion of the old version is necessary, the column definition having the usage period of the old version is used.
4) Add version information to the company code (version) constituting the table ID and column ID, and refer to the version information.

Feature 7: Item relation definition table 1) It is possible to define a relation (item relation definition) between different formats in the item relation definition table.
2) Data conversion between different formats (A⇔B) via the standard format becomes possible. Compared with the conventional mapping for direct format conversion, the system configuration is greatly simplified.
3) In addition, the data conversion program itself can be defined in the function management table (program operation contents and parameter outing). Then, by referring to the value (function information) stored in the data item “function” of the item relation definition table, it is possible to perform a predetermined calculation process on the value of the column ID. In addition, program contents and parameters can be changed simply by changing the contents of the function management table (data input processing), and there is no need to change the program itself.
4) For example, when format A (ordering party unique) is converted to format B (ordering party unique), between each item of A (ordering party F) and each item of S (standard F) via standard format S Chain (link information) is defined in advance (A⇔S), and a chain (link information) between each item of S (standard F) and B (orderee F) is defined in advance (S⇔B). ). Thus, data conversion between A (ordering party F) and B (ordering party F) is executed using S (standard F) as an intermediary.
5) A standard format (standard profile) can be created for each industry (for each type of business).
6) In the column chain table, when an A format data item (for example, a data item having an orderer profile) serving as a trigger is input, a data item in a standard format corresponding to the data item (a data item corresponding to the standard profile) ) To obtain a B format data item (corresponding data item of the contractor profile) corresponding to the standard format data item.
7) Specifically, data conversion processing is performed as follows. First, in the column management table, a standard profile (one) that defines a standard data format corresponding to a specific business (for example, ordering business) and unique data used by a specific client company or organization for that specific business Customer profiles that define the format (only the number of client companies / organizations) and user profiles that define the user's own data format used by users who trade with the company / organization for the specific business (usually one) Are created and stored as master data. Further, link information between a specific data item of the supplier profile and a data item of the standard profile corresponding to the data item is stored in the item relation definition table. Specifically, the column ID of the data item of the supplier profile and the column ID of the data item of the standard profile corresponding to the data item are stored and associated in the same row of the inter-link column management table in a one-to-one relationship. Link. As a result, all data items in the supplier profile and all data items in the standard profile correspond (link) one-to-one. Similarly, link information between the data item of the standard profile and the data item of the user profile corresponding to the data item is stored in the item relation definition table. Specifically, the column ID of the data item of the user profile and the column ID of the data item of the standard profile corresponding to the data item are stored and associated in the same row of the inter-link column management table, and are linked one-to-one. To do. As a result, all data items of the user profile and all data items of the standard profile correspond (link) one-to-one. Therefore, for example, when converting customer profile data (customer data) into user profile data (user data), refer to the field-related definition table, and link with the column ID of the data item of the user profile. The column ID of the data item is acquired, and then the column ID of the data item of the customer profile linked to the column ID of the data item of the standard profile is acquired. Then, with reference to the value management table, the value of the column ID data item of the acquired supplier profile is acquired as the value of the corresponding column ID of the user profile. Thereby, the data conversion from the customer data of the customer profile to the user data of the user profile is realized via the standard profile.
8) Next, the output / display (print / screen display) of the data stored in the value management table is processed as follows. First, the data stored in the value management table is only supplier data as primary data (read data) for the purpose of maintaining the integrity of the data. Therefore, when outputting and displaying the user data corresponding to the customer data, the value of each data item of the customer data corresponding to each data item of the user data is changed to the data item corresponding to the standard profile as described above. Via the value management table, and each acquired value as the value of the corresponding data item of the user data according to the user profile (in a format unique to the user data), in a set (set) with the data items of the user data Output and display. At this time, the display format (the size of the display frame as a parameter for controlling the output image, the display position of each data item, the font, etc.) is defined in the display program. Alternatively, as will be described later, a form (screen) definition table (FORM_COLUMN table) that defines a display format may be prepared and parameters may be set out. In this way, it is not necessary to change the program each time the display format is changed, and the display format can be easily changed.

Feature 8: Item value management table 1) Automatic conversion (column value) ⇒ Differences in the meaning of item values are defined in the table, so that only the table data items and their values are changed compared to the case of processing with a program. The system configuration is simple. In addition, data item values can be standardized.

Feature 9: Data structure of the ordering system (table structure)
1) Contents of column management table Table ID = company code + data type code + branch number. Each table ID uniquely represents each record type of one data composed of records of a plurality of hierarchies (for example, in the case of ordering data, a file header record, a slip header record, a slip detail record). The serial number (sequence NO) in the column management table indicates the order of data in the same table ID. The column ID may be a unique ID that is automatically generated based on the company code, data type code, branch number, and serial number. An item name, that is, a name of a data item (field) is given to each column ID. That is, each column ID uniquely represents each field type and attribute (definition contents) of one record consisting of a plurality of fields (for example, in the case of a file header record, the record classification, data type, data creation date, etc.) Field name, data type, position, maximum / minimum number of bytes, sequential number of identifier, main storage information number, column sub ID, etc.). Further, as described above, date information can be used for version management. Further, since the last two digits of the company code represent the version of the format of the company, it can also be used for version management. As the main data item, the column ID (company (version)) uniquely identifies each data item (each field), and the table ID + sequence No. (Serial number) and one-to-one correspondence (table ID + sequence number is generated and processed). The conversion method (function) defines a method name used for the conversion when the data item value of the column ID needs to be converted (for example, COLUMN_VALUE). The position indicates the position of the data item from the record head (0). The length indicates the maximum / minimum length. The identifier creation order designates the order of the data items constituting the identifier (search key) of the record (for example, in the case of a file header record of order data (1) ordering company code (2) data type (3) data creation Date, slip header record (1) slip number, slip detail line (1) detail line number (2) GTIN code). Also, the basic item specification order is the basic data item to be copied to the row table among all the data items (all fields) of the record, to which basic information of the row table the value of the main data item is copied. Specify by serial number (Example: In the case of an ordering data file header record (1) Ordering company code (2) Ordering company code (3) Data type (4) Data creation date (5) Total number of data records, slip header In the case of a record (1) slip number (2) slip classification (order date) (3) order date (delivery designation date) (4) delivery company code (store code) (5) delivery store code (business name) (1) GTIN code (2) Product name Kana (3) Standard Kana (4) Quantity (5) Original unit price). The column sub ID specifies the object ID of the data item (refer to the target management table) when the value of the data item is stored in the matching item of the row table (for example, in the case of a file header record of ordering data) ⇒ (1), in the case of an order store code slip header record (1) slip number (2) order date (or (1) slip number (2) order date (3) store code), in the case of a slip detail line (1) ) Slip number (2) line number (3) GTIN code). Also, the valid date (self) & (solstice) can be used for version management.

Feature 10: Data entry (data reading) processing of ordering / ordering system ⇒ Control information (CONTROL_INI) is defined in the table management table, and data is input. Therefore, only the same CONTR0OL_INI as the data item value is used for changing the data format. The program (internal parameters) need not be changed.
1) Divide the volume of the data management system (eDIY) of the user company for each company (ordering company that is the customer company), and specify the company (ordering company) of the data (read data) to be processed when starting the system .
2) Before data exchange, refer to the data exchange management table (ordering company code, ordering company code, data type, etc.), and the specified company (ordering company) sends the transaction (ordering) to the user company (ordering company). Check whether or not.
3) With reference to the record size (for example, 128 bytes, 256 bytes, 512 bytes, etc.) of the table management table, the read data is read in order in the record size unit (128 bytes, etc.).
4) At the same time, for each read record, record control information (CONTROL_INI) defined for the company's data profile (data format) in the table management table (item value indicating a specific record) The table ID code having the record control information that matches the read record is identified and acquired.
5) Referring to the column management table, the portion corresponding to the table ID code of the column management table is read into the memory.
6) A row management (ROW) table is created by assigning (automatically generating) row IDs to the records read out in order (eg: ordering company code (version) + ordering company code (version)) + Data type + reading date + reading time).
7) At the same time, referring to the column sub ID (= object ID) of the column management table, the item value of the matching item defined for the table ID is assigned to each row ID from the data item value of the record having the table ID. Store. For example, for a slip header record, if a delivery store code (column sub ID = 11), a slip number (column sub ID = 20201), and an order date (column sub ID = 20101) are defined as matching items, the item value The store code value (100), the slip number value (49218 ***), and the order date value (20050113) are stored as the matching item value of the slip header record. In addition, for a slip detail record subordinate to the slip header record, a delivery store code, a slip number, a detail row number (202011), a GTIN code (column sub ID = 3), and an order date are defined as matching items. , Store code value, slip number value, detail line number value (01 etc.), GTIN code value (049 ************), order date The value is stored as the matching item value of the slip detail line record. In this way, data item values (for example, store code, slip number, etc.) required in the matching operation of the ordering / ordering data are defined in advance in the column management table as matching item values. As a result, for example, when a missing item (for example, an acceptance quantity 30 for an order quantity 50) of a specific line of a specific slip number is found in a picking operation, the user company (based on order data) When creating the shipping data to be created, by inputting the shipping quantity (inspection quantity) reflecting the quantity of missing parts, the status of the missing part (order quantity is doubled) through the matching between both matching item values. It is possible to automatically fill in the shipment slip (automatic reflection of correction due to reconciliation).
8) At the same time, referring to the basic item designation order of the column management table, the basic item value defined for the table ID is assigned to each row ID from the data item value of the record having the table ID and stored. For example, if the order date, delivery date, and inspection date are specified as basic items for the slip header record, the item values (and attributes) are stored, and the GTIN code, slip number, detail line for the slip detail record When the number and GTIN code are defined as basic items, the store code value (and attribute), slip number value (and attribute), line number value (and attribute), and GTIN code The value (and attribute) is stored as the basic item value (and attribute) of the slip header record. Thereby, at the time of data display output, only the basic item values in the row management (ROW) table can be read and displayed quickly.
9) Furthermore, a row management table can be created by storing other data item values (table ID, identifier ID, identification value, etc. of the record).
10) Simultaneously with the creation of the row management table, the records read out in order are referred to the column management table, and according to the serial number of the table ID or the column ID, all the data items (fields) constituting the record are recorded. A value management table is created by dividing the data item values in order and storing each data item value in a corresponding value storage cell (values 1 to 30). At this time, the value storage cell is a physical cell for storing each data item value (value of each field) ("value 1 ..." and "row" as "column (data item)" of the value management table). The column or storage area that intersects with the “row ID” as logically, but logically, the table ID (assigned for each record of each format type of FH, DH, DD) and (uniquely for each record) All fields of one record are stored in a logical cell (a column or storage cell where a series of table IDs as a column intersects with a row ID) uniquely determined by a row ID (assigned). It is an image. In this way, it is possible to improve the processing speed as compared with the case where the column where the column ID and the row ID intersect is one logic cell and the value of each field is stored in the one logic cell. That is, all the fields of one record are stored in one logical cell determined by the table ID and the row ID, and those fields are a series of values belonging to the one record. Using the key, it is possible to quickly obtain a value.
11) When the number of data item values stored in each logic cell of the value management table is 31 or more, the second logic cell is continuously provided after the logic cell, and the cell sequence NO of the second logic cell is provided. From “1” to “2”, the 31st and subsequent data item values are sequentially stored in the value storage cells (values 1 to 30) of the second logic cell in the same manner as described above.
12) When all values of all records of the order data are stored in the value management table, the order data becomes primary data. Therefore, the subsequent unified slip data (29), arrival schedule data (slip) (30), arrival schedule data (packing) (40), receipt data (50), billing data (60), payment data (70) For data output in display (form printing / screen display) or specific format (specific slip format, etc.), refer to the item-related definition table, and link information between the data item of the primary data and the corresponding data item of each data. It is acquired and executed in such a manner that the data item of the primary data is replaced with the data item of each data. As a result, it is possible to display (print / display) various forms and various screens and output data while ensuring the unity of data by always using primary data.
13) When data reading is fully automated, the following processing is performed. However, it is necessary to uniquely identify a record by CONTROL_INI (not possible if CONTROL_INI is duplicated). That is, data is read in the same manner as described above. However, the same processing as described above is performed for all the ordering companies without specifying the ordering company of the read data. In this case, complete automation can save a lot of time, but the processing time is increased accordingly. Next, the type of input data (for example, order data) is discriminated and analyzed with reference to the table management table (for example, from the data title or the like), and the data is divided into each record. At that time, a table ID (+ record sub ID) corresponding to each record is assigned. Then, the record definition of the corresponding table ID (+ record sub ID) is acquired by referring to the column management table. At the same time, a row management table and a value management table are created.

Feature 11: Data conversion between different formats and data display (form screen display or printing) / data output (CSV output / save) processing in a specified format. As a result, the data is centrally managed (displayed in an equivalent view using the ordering company data (primary data)) ⇒ Data whose quantity has changed from the ordering company data, such as delivery data and billing data of the user company, Data is output using output data (CSV) in which only the corresponding item of data is changed (based on ordering company data). Thus, data integrity is maintained.
1) First, the column management table corresponds to each data type (order data, unified slip data, scheduled arrival data (ASP), receipt data, billing data, payment data, return data, etc.) of the ordering business as a specific business. The standard profile (one for each data type) that defines the number of standard data formats to be used, and the data type that the ordering company uses (order) Ordering company profile (one for each data type of each ordering company) that defines the number of data, unified slip data, receipt data, payment data, return data, etc.) and the data format unique to the user company for the ordering business The data type used by the user company (order data, unified slip data, scheduled arrival data (ASP), The user enterprise profile (usually only defines the number of determined data, etc.) one) and to create each stored as master data.
2) Further, link information between a specific data item of the ordering company profile and a data item of the standard profile corresponding to the data item is stored in the inter-link column management table. Specifically, the column ID (9999901201003) of the data item (example: data creation date) of the ordering company profile and the column ID (1201003) of the data item (data creation date) of the standard profile corresponding to the data item are They are stored in the same row in the inter-link column management table and linked one to one. As a result, all data items of the ordering company profile and all data items of the standard profile correspond (link) one-to-one. Similarly, link information between the data item of the standard profile and the data item of the user company profile corresponding to the data item is stored in the inter-link column management table. Specifically, the column ID (111111101201003) of the data item (data creation date) of the user company profile and the column ID (1201003) of the data item (data creation date) of the standard profile corresponding to the data item are linked. Stored in the same row of the column management table and linked one-to-one. As a result, all data items of the user company profile and all data items of the standard profile correspond (link) one-to-one.
3) Therefore, for example, when converting data of an ordering company profile (eg, ordering data) into data of a user company profile (ordering data in a user-specified format), first, according to the data content (ordering data) specified by the user By referring to the inter-link column management table, the table ID (11111101201 etc.) of the user profile (order data profile) of the specified data (data to be displayed) is determined, and the columns of all data items belonging to the table ID IDs (11111101201001, etc.) are acquired in order (for all data items of the profile). Next, with reference to the inter-link column management table, the column ID of the data item of the standard profile to be linked with the column ID of the acquired data item of the user profile is acquired. The column ID of the data item of the ordering company profile to be linked is acquired. Then, the value management table storing the order data value of the ordering company profile is referred to, and the value of the column ID data item of the obtained ordering company profile is associated with the user company profile in the item order (column ID order). Is acquired as the value of the column ID. Thereby, the data conversion from the customer data of the customer company profile to the user data of the user company profile is realized via the standard profile.
4) Next, the display of data stored in the value management table (form printing / screen display) is processed as follows. Here, the data stored in the value management table is only the ordering company data (default data) in the ordering company profile format as the primary data (read data) for the purpose of maintaining the integrity of the data. Data in the standard profile format (standard data) and user company profile format data (user-specified data) are not actually stored in separate (specific to them) value management tables. A general (conventional) physical structure is obtained by acquiring the value of the data item of the ordering company data from the stored value management table and displaying the value as a set with the data item of the standard profile or user company profile. Display with the same view as the table of. Then, when ordering company data in the ordering company profile format is displayed as it is, naturally, data conversion is not necessary, so the column management table is first referred to. On the other hand, when displaying data in a display format designated by the user company (user designation data), first, the table ID (11111101201 etc.) of the user profile (order received data profile) is determined, and all data belonging to the table ID is determined. The column IDs (11111101201001 etc.) of items are acquired in order (for all data items of the profile). Next, the column management table is referenced, then the inter-link column management table is referenced, and then the value management table is referenced. Therefore, when displaying the user data corresponding to the customer data, the value of each data item of the ordering company data corresponding to each data item of the order data according to the user company profile specified by the user company is set as described above. Is obtained from the value management table via the corresponding data item, and each acquired value is set as the value of the corresponding data item of the order data specified by the user company according to the user company profile (the order data unique to the user company is specified). In the format), it can be output and displayed as a set (group) of data items of order data specified by the user company. At this time, the display format (the size of the display frame as a parameter for controlling the output image, the display position of each data item, the font, etc.) is defined in the display program. Alternatively, as described above, a table (FORM_COLUMN table) that defines a display format may be prepared and parameters may be set out. In this way, it is not necessary to change the program each time the display format is changed, and the display format can be easily changed. On the other hand, when converting customer profile data (customer data) to user profile data (user data) and outputting (printing / displaying), first, the standard profile linked to the column ID of the data item of the user profile The column ID of the data item is acquired, and then the column ID of the data item of the supplier company profile linked to the column ID of the data item of the standard profile is acquired.

Feature 12: Form column (FORM_COLUMN) table and form (FORM) table 1) Basically, data conversion between “table and table”, but as an additional specification, data conversion from table to form (FORM) is also possible.
2) The form print display format (form image file, image display position, character display position, length, font, font size, etc.) previously defined as parameters in the program is taken out of the program. Defined in the FORM_COLUMN table. Therefore, it is possible to cope with a format change of various forms simply by updating the FORM_COLUMN table (just by inputting data). The FORM_COLUMN table is a table that associates the column data item values with the data item values of the book table on a one-to-one basis. In addition, the book table is dynamically changed by adding / deleting / changing data so that the data item of the column is dynamically changed. Conventionally, it has been necessary to change the book table by a program.

Characteristic 13: Display screen column (FORM_COLUMN) table and display screen (FORM) table 1) Furthermore, data link is possible between table ⇔ display screens.
2) The form screen display format (form image file, display position, character string display position, length, font, font size, etc.) that was previously defined as a parameter in the program is taken out of the program, and the FORM_COLUMN table Defined in Therefore, it is possible to cope with format changes of various display screens only by updating the FORM_COLUMN table (just by performing data input work). In addition, the screen ⇔ column is all possible with one program (without modifying the program) just by tampering with the data.
3) Also, the display field of the form displayed on the screen is defined in the table as an input area. Therefore, customer input can be made using the same screen. Also, the book table displayed on the screen can be regarded as a screen, and each frame can be used as an input area. The data content check can also refer to the definition (attribute) of the column management table (for example, error processing when a number is entered in the date). In addition, the user can select a desired data item by looking at the attributes of the column management table and displaying a list such as a drop-down list. Data compatibility comes from looking at column values. The chain can be used as input.
4) Customer order input When the user system is activated, the user can select a volume definition (which customer company (ordering company) volume is to be output first). When the volume is selected, the user system is launched and the “customer input” menu is displayed. The menu has an input field. A purchase slip can be entered against a delivery form in a predetermined format. A conventional display program outputs data item values (corresponding to data item values in a value management table) stored in a DB work area to a predetermined position of a form (delivery slip) in a predetermined format displayed on the screen for display. To do. On the other hand, the present invention associates the COLUMN table with the FORM_COILUM table on a one-to-one basis, and stores values in the corresponding data items of the value management table having the table ID of the COLUMN table from the FORM table via the FORM_COLUMN table. Using a form actually displayed on the screen, a necessary value can be directly input to the display column of the form.
5) Attributes can also be entered in the column management table.
6) The FORM_COLUMN table handles data specialized for input (display location, size, font type, etc.).

Feature 14: Matching of order data and delivery data, correction reflection processing 1) Delivery store code, slip number, GTIN code, order date, etc. can be specified as a match item (index item (search key) at the time of search).

Feature 15: The above data is distributed and ASP realization is achieved (for example, FIG. 17).
1) Refer to the same data definition and operate (exit the column definition, manage it by the management organization and distribute it to the user).
2) Application to electronic medical records is also possible. For example, the definition (format) and standard definition of Gifu Prefecture and its chain can be downloaded and mapped with the definition of its own prefecture (Tokyo, etc.).

Feature 16: Data distribution (first time distribution, first time system operation)
1) A user downloads distribution data by FTP (automatic deletion after downloading).
2) Obtain user company information from the customer management table.
3) Obtain business relationship information from the data exchange management table.
4) The standard profile selected by the user company is acquired from the column management table, and the column value is acquired from the item value management table.
5) A table management table, a column management table, an item value management table, and an item relation definition table are used for the company profile of the business partner.
6) When a standard profile is copied into a user profile, the user profile is determined from the column management table and the item relation definition table.
7) When the number of business partners increases or decreases after system operation, the same processing from (1) to (6) is repeated. Then, the user reselects a business partner who conducts electronic commerce.

Feature 17: Profile Version Upgrade 1) Company Profile Version Upgrade Processing (Common)
The user's system automatically (or after the user confirms) the system of the system support center when the system is started or by monitoring the timer after the startup, and notifies the center system of the current company profile version. At this time, the user ID is used.
1-1) When the version of the company profile of the user system is old, the center system notifies the user system of the fact and the contents of version upgrade. Only when the user clicks the update button, the center system upgrades the company profile. At this time, the user is prompted for confirmation for each company (one company profile that has been upgraded) designated by the user system.
1-2) When the upgrade is completed, the user system notifies the system support center of the status.
2) Company profile version upgrade information (common)
2-1) The user's system automatically accesses the system support center system (or after the user's confirmation) at the time of starting the system or by monitoring the timer after the starting, and information on the company profile currently used Notify the center system. At this time, the user ID is used.
2-2) If the company profile is scheduled to be upgraded, the user system accesses the WEB of the system support center and displays a page on which the contents of the upgrade can be confirmed. At this time, the URL (URL of the page storing the upgrade information) for each company (one company profile to be upgraded) scheduled to be upgraded is displayed.
2-3) The coping method when the version is changed is also displayed at the same time.
2-4) Enable system startup in test mode.
2-5) With the new company profile, the user system refers to the date information in the old and new column management table that defines the new and old company profiles (such as the available start date and end date of the new profile). Execute. At this time, the user system prompts backup (and deletion) of accumulated data in the old format (old profile format). In order to prevent accidents, the user system keeps the old version of the company profile, but makes it unavailable for data conversion by using the date information (usable start date, deletion date, etc.) of the column management table.
3) Standard profile version upgrade processing (common)
3-1) The user's system automatically accesses the system of the system support center (or after the user confirms) at the time of starting the system or by monitoring the timer after the starting, and the current standard profile version is stored in the center system. Notice. At this time, the user ID is used.
3-2) When the version of the standard profile of the user system is old, the center system notifies the user system of the fact and the contents of version upgrade. Only when the user clicks the update button, the center system upgrades the standard profile. At this time, the user needs to specify the definition of the relationship between the user profile and the new standard profile (new item related definition table generation), but the user system must specify the old standard profile and the user (specified by the user company before). It is assumed that the old user profile is generated by referring to the profile definition (item relationship definition table).
3-3) When the upgrade is completed, the user system notifies the system support center of the status.
4) Standard profile version upgrade information (common)
4-1) The user's system automatically accesses the system of the system support center (or after confirmation by the user) at the time of system start-up or by monitoring the timer after the start-up, and information on the standard profile currently used is used. Notify the center system. At this time, the user ID is used.
4-2) When the upgrade of the standard profile is scheduled, the user system accesses the WEB of the system support center and displays a page on which the contents of the upgrade can be confirmed.
4-3) Unlike when upgrading the company profile, before switching the standard profile, a sufficient test of the new standard profile at the user company using the original user profile (operation test using the new standard profile) However, the standard profile version itself is automatically updated by the program (see (5) below).
4-4) The operation timing (standard profile switching timing) in the new standard profile is specified by the user, but when switching between the old and new standard profiles, the user system uses the date information (usable start date / end date) in the column management table. It is preferable to perform automatic switching using a date or a deletion date).
4-5) The standard profile is not upgraded when the company profile is upgraded or a new company profile is added, but the version is updated when the system itself is upgraded (for example, XML support). Up.
5) Standard profile version upgrade processing program 5-1) Refer to the three relationships (related definitions in the field-related definition table) of company profile ⇔ old standard profile, user profile ⇔ old standard profile, old standard profile ⇔ new standard profile. , A program that creates a new definition of a relationship between a company profile and a new standard profile, and a new definition of a relationship between a user profile and a new standard profile (updates the item relation definition table by reflecting it in the item relation definition table).
5-2) At this time, the related definition of the old standard profile and the new standard profile and the related definition of the company profile and the new standard profile are created first on the system support center side and distributed to the user system. This related definition can be created by the upgrade process program as described in (1) above.
5-3) User profile The new standard profile related definition creation process is executed by the user system.
5-4) The old standard profile is invalidated when all profiles (company profile and user profile) chained (linked) with the old standard profile are invalidated.
6) Upgrade user profile (common)
6-1) The user can arbitrarily upgrade the version. When the system support center also supports the user profile, the user system accesses the support center and notifies the support center system of the user profile information being used. At this time, the user ID is used.
6-2) Then, the same processing as that for upgrading the company profile is executed.
7) Suspension of use of company profile 7-1) When a user company suspends use of a specific company profile (which has been used so far), definition information (column management) of the canceled (suspended use) company profile Since the corresponding part of the table is necessary when browsing the past data (in which the company profile is used), it is set so as not to be deleted from the DB of the user system.
7-2) However, after the cancellation, control is performed so that the user company cannot convert data using the company profile. For example, this is handled by checking the consistency between the user key value of the user company and the usage status of the canceled company profile.

Feature 18: Correspondence to electronic book storage method A slip is stored as a delivery note image in SLIP (slip backup area) in a volume configuration in an uneditable data format (for example, an image file such as JPEG).
Automatic input of read data 1) In order to set a volume for each company, if there are 300 suppliers, there are also 300 volumes. The user selects the volume corresponding to the read data from these, and stores the data in the volume corresponding to one company. When data comes in every day, it is troublesome to select the data storage target volume and input the data each time. Therefore, this is dealt with by creating an automatic execution program.

Feature 19: Support for multiple industry specifications 1) When operating systems in different industries (for example, home center industry and drugstore industry) such as A industry, B industry, etc., A industry standard profile and B industry standard Establish definitions related to profiles (for example, home center standard⇔drug store standard). As a result, it becomes possible for the user company to conduct business transactions in a plurality of industries. For the A industry, the definition of the company profile (A company ordering company) and the A industry standard profile (A company ⇔ A standard), the definition of the A industry standard profile and user profile (A standard ⇔ user) ) Are defined, and data exchange between the company profile of the A industry and the user profile is realized through these two relation definitions (item relation definition table). In addition, for the B industry, the definition of the relationship between the company profile (in the ordering company of the B industry) and the standard profile for the B industry (B company ⇔ B standard), the definition of the relationship between the standard profile for the B industry and the user profile (B standard) (User) is defined, and data exchange between the company profile of the B industry and the user profile is realized through these two relation definitions (item relation definition table).
2) The user company needs to define a plurality of standard profiles (A standard, B standard,...) And their own user profiles. In this case, the system support center has a standard definition for each industry, such as A industry, B industry, etc. (old standard profile-new standard profile), a definition between standard profiles in different industries (A industry standard profile) ⇔B industry standard profile ...) is created and the user system downloads these related definitions. Then, the user system automatically creates a user profile with reference to these related definitions.

  Next, by applying the data management system based on the three tables (column management table, row management table, value management table) detailed in the first to tenth embodiments, the heterogeneous systems, the heterogeneous package software, and the heterogeneous infrastructure are applied. Various embodiments of a system exchange profile (SXP) service system as a data management system capable of performing general data exchange and data conversion between them will be described. The system exchange profile (SXP) service system according to the present invention defines data maintained by each system using the column management table in order to realize data exchange between the systems. The system exchange profile (SXP) service system according to the present invention refers to the definition information as a system exchange profile (abbreviated as SXP), and provides a service for distributing the SXP and the SXP service. These providers are referred to as SXP service providers, and it is intended to promote effective utilization of information in small and medium-sized enterprises by spreading this service form to society.

  Here, the background technology of the present invention will be described. In recent years, systems using XML and Web 2.0 have been born one after another, and the keyword indicating the fourth pillar of management strategy in a company is “IT (Information Technology)”. To “ICT (Information & Communication Technology)”. In other words, the time has come when information that has been managed in organizations such as companies so far is exchanged or merged with information managed in other organizations and used as information with new added value. I can say that. However, while the technology that is exchanged or integrated on the Web (Web) continues to advance, the actual situation is that there is not much technology that can effectively utilize data managed especially in SMEs. . Therefore, the present inventor provides a system exchange profile (SXP) service system as described below in order to solve the above-described problems. That is, a sound system must consistently output the same output if it performs a procedure that is standardized by verified programming. The system exchange profile (SXP) service system and the business model using the system exchange profile (SXP) service system realize conversion and exchange of data managed and maintained in any sound system, or data fusion Data exchange is an innovative extension of effective use of data that crosses the barriers between companies, systems, and infrastructure.

  A system exchange profile (SXP) service system according to the present invention is a general-purpose shared ASP (Application Service Provider) or SAAS (Thirds :) that enables the exchange or fusion of all data managed by each organization such as each company / organization. It can be applied to Software as a Service. On the other hand, regarding the data exchange among the data exchanges, exchange of various information such as product information, order information, inventory information, and accounting information exchanged by electronic commerce (EC), electronic data exchange (EDI), etc. Realize fusion. This data exchange / fusion includes, of course, the data exchange / fusion in the embodiments described in the first to tenth embodiments. In addition, regarding data exchange between systems, the difference in data format between systems is resolved, for example, between two different business systems or between two different commercial package software (for example, sales management software and purchase management software). Realize data conversion and data fusion required when exporting and importing data. Furthermore, with regard to data exchange between information infrastructures, various database systems such as relational databases (RDBs) that will be widely used as information infrastructures will be realized by mutual conversion between data stored in databases and XML data. Data exchange and fusion with XML usage systems (including XML databases) that are increasingly expected to be utilized.

  In order to solve this problem, the system exchange profile (SXP) service system according to the present invention provides the following solution. Here, the conventional data exchange will be explained first. In order to realize the data exchange between systems, generally, first, export file is output from the migration source system, and then refer to the import file of the migration destination system However, machining work using spreadsheet software or the like is required. This work is not so difficult as long as you have some IT knowledge. However, valuable work hours are still spent on the work, and the know-how is stored in a spreadsheet macro or in the memory of the worker, and specifications are created and disclosed to a third party. Examples are rare. In other words, despite the fact that a considerable amount of time is spent to exchange data between systems, the method is entrusted to one person in charge, and the validity of the data is determined by a third party. The actual situation is that there is no check, the mechanism of the machining operation is not guaranteed as a consistently consistent work, and there is no assurance that it will be maintained soundly. Also, if the data managed by a system such as packaged software is used correctly, the data will be migrated through a sound system even though the correctness and consistency of the data is ensured and guaranteed. Or, it is rarely performed while following consistent migration rules. Therefore, in the data migration work, there are many cases where the legitimacy and consistency of data are often lost.

  Therefore, the present invention does not require IT technology expertise and can be used safely and inexpensively in modern times where the introduction of IT technology or ICT technology is indispensable for management innovation of SMEs. The first mechanism (system) that can maintain the consistency of data or can centrally manage the information on the same management target is provided, and the introduction of ICT by SMEs is innovatively promoted. As the first mechanism (system), the following mechanism (system) and a business model to which each system is applied (for convenience, “SXP feature 1, SXP feature 2...”) Are provided.

  SXP features Providing a system (system) that automates the process of processing an export file of a certain system (package software, etc.) and processing an import file of another type of system (package software, etc.) and a business model that applies each system . As a result, in the system and business model using the system, the work of processing the migration destination import file from the migration source system export file that is considered essential for the data migration work is realized.

  SXP features Provide a system (system) that defines output data of a stable system such as package software, maintains and manages the definition information (system profile), and a business model that applies each system. As a result, the definition information of data managed by any system is defined as a system exchange profile (SXP) as a core for the automation, and storage and maintenance of the SXP is realized.

  2. SXP feature Provision of a system (system) that downloads and distributes system profiles from websites and a business model that applies each system. Thus, the maintenance-managed SXP is downloaded from the website and distributed to the user.

  SXP Feature 4. Use of two system profiles to provide a mechanism (system) that mutually realizes data exchange between two systems via a standard profile, and a business model to which each system is applied. As a result, by using the above system and acquiring the SXP of the two systems, automation of the processing work necessary for data migration is realized, but data conversion and exchange is realized via a standard profile. By using this standard profile, the system investment will be greatly reduced.

  4. SXP feature Provide a system (system) that uses multiple system profiles and refers to various information stored in multiple systems by referring to the right person in the right place and a business model that applies each system. As a result, by using the above system and acquiring a plurality of SXPs, it is possible to merge and store all the various data stored in the plurality of systems, and to scrutinize data inconsistencies between the systems. .

  5. SXP feature A system (system) for easily converting stored data into various data formats such as fixed-length text, variable-length text, CSV file, XML file, etc., and provision of a business model to which each system is applied. As a result, the stored data is referred to, converted into various formats designated as necessary, and the data is output to realize secondary use of the data.

  Next, the present invention intends to further expand and further expand the series of systems and business models from SXP features 1 to 6 so that they can be used between other industries or corporate groups. That is, the present invention provides the following second mechanism (system) in order to horizontally expand and expand the infrastructure that facilitates data exchange and data exchange business between the companies or systems. Provided (displayed by serial numbers following SXP feature 1 to SXP feature 6).

  6. SXP feature Provision of a system (system) for uploading and storing system profiles on a website and a business model to which each system is applied. This realizes uploading and storing the SXP through the website.

  SXP feature8. Providing a system (system) that defines standard profiles for each industry unit or each managed object unit, and a business model that applies each system. As a result, using the above system, it is possible to formulate a standard profile for each industry or management target and upload it to a website.

  8. SXP feature Provision of a system (system) that defines system profiles and relationships with standard profiles, and a business model that applies each system. Thus, the system development vendor refers to the standard profile, selects a related standard profile of the developed system, defines SXP corresponding to the development system, and uploads it to the website.

  SXP feature10. Promote the sharing of the header (header of each data) that identifies the system profile, and provide a mechanism (system) that automates data migration between companies and systems, and a business model that applies each system. As a result, the header part of the SXP profile is made common, the common format is spread, the SXP for determining the detailed information that is the main body of the data is referred to in the data acquisition area, and the data is immediately converted and exchanged. Realize.

  SXP features11. Provision of a business model that applies each system and a system (system) that can automatically start a corresponding application by simply sending data and convert and exchange data. As a result, the data conversion & exchange referring to the SXP is automatically started, and after the input data transmitted to the designated pre-conversion folder is converted and exchanged, it is transferred to the designated post-conversion folder. .

  Hereinafter, specific embodiments of the SXP service system and a business model using the system will be described.

Embodiment 11
First, the background art of the SXP service system according to the eleventh embodiment will be described. FIG. 78 is a data flow diagram schematically showing an aspect of data conversion between a plurality of conventional enterprise systems.
As shown in FIG. 78, each company's own system is operating between the companies with which there is a transaction. For example, company A (system of company A) 700 manages product data 701, supplier data 702, sales data 703, purchase data 703, and other data 705. The company B (system of company B) 710 manages product data 711, supplier data 712, sales data 713, purchase data 713, and other data 715, similar to the company A 700. Normally, the profiles (data formats) of company A 700 and company B 710 are unique to each company and are different. The data managed by the two systems 700 and 710 has many similar tables and data items because there is a transaction between them. For example, data exchange between the company A 700 and the company B 710 is performed between the two companies such as the product data 701 and the product data 711, the business partner data 702 and the business partner data 712, the purchase data 704 and the sales data 713. Data exchange according to transactions (ordering business) between the two. Although both systems 700 and 710 are illustrated as handling the same data for the sake of convenience, there are actually data items that do not match. These data are to be exchanged by EC, EDI, etc., and should be used effectively between trading companies. However, since actual data exchange is performed in a file-to-file manner, the development and operation of the data exchange system is very expensive. Therefore, recently, a shared EDI platform using XML has been constructed and dissemination activities are being carried out (COXEC, XBRL, etc.).

FIG. 79 is a data flow diagram schematically showing an aspect of data mapping in data conversion between a plurality of conventional enterprise systems.
As shown in FIG. 79, in the case of an ordering business between two companies, a predetermined conversion rule (data mapping) between the ordering data 800 on the ordering company (business partner) side and the ordering data 810 on the ordering company side. Accordingly, for example, the store code 801 on the ordering company side is converted into the store name 811 on the order receiving company side, and also converted into the address or telephone number of the delivery destination of the product. The order date 802 of the order data 800 is converted into the order date 812 in the order data 810. At this time, for example, the ordering company manages the order date in the Western calendar, but the ordering company manages it in the Japanese calendar. May need to be converted. Further, when the product code 803 is managed by the in-store code in the ordering company, the ordering company needs to convert the product code 803 into the JAN code 813 as a unified code. The product name 804 in the order data 800 is converted as the product name 814 in the order data 810, and the order quantity 805 in the order data 800 is acquired as the order quantity 815 in the order data 810.

FIG. 80 is a data flow diagram schematically showing an aspect of data stored in a conventional application system (package software).
As shown in FIG. 80, the package A 900 as package software stores various data such as product data 910, customer data 920, sales data 930, purchase data 940, and other data 950. The package A900 can be output to a CSV file or the like by exporting all or part of various data. This is often used when data stored in the package A 900 is reused in another system. The package A900 can be input from a CSV file or the like by importing all or part of various data. This is often used when data handled by the package A 900 is acquired from another system and imported.

FIG. 81 is a data flow diagram schematically showing an aspect of data conversion between a plurality of conventional application systems (package software).
As shown in FIG. 81, the CSV file exported from the package A 900 is often used by spreadsheet software or the like. However, it is almost impossible to input the file output from the package A 900 as it is to another type of package software, for example, the package B. That is, even when package B1000 stores and handles various data such as product data 1010, customer data 1020, sales data 1030, purchase data 1040, and other data 1050, which is the same data as package A900, data is usually used. Since the formats are different, data such as a CSV file exported from the package A 900 cannot be imported into the package B as it is (data format). Therefore, normally, after the output file of the package A900 is once taken into the spreadsheet software, it is necessary to perform an operation for processing the data corresponding to the data format of the package B1000 while looking at the specification sheet. If this processing operation is simple processing, it is easy. However, when the correspondence relationship is 1 to N and N to N, the processing operation becomes complicated and management of the intermediate file becomes very troublesome. In particular, there are many companies that are difficult to carry out the above-described processing work among small and medium-sized enterprises that have been delayed in introducing IT.

FIG. 82 is a data flow diagram schematically showing a manual data processing operation at the time of export / import in data conversion between a plurality of conventional application systems (package software).
The problem shown in FIG. 81 will be described using the product data 910 as an example. As shown in FIG. 82, the product data 910 of the package A900 includes a product code 911, a product name 912, a standard name 913, a unit price 914, and a supplier code 915. The product data 1010 of the package B1000 includes the product code 1011, the product The name 1012, the product name Kana 1013, the lower price 1014, and the upper price 1015 are assumed. In this case, the product code 911 of the product data 910 can be used as it is as the product code 1011 which is a key item of the product code 1010 when the product code system is the same, but when converted into a unified code such as a JAN code or GTIN code There is also. In the product code 900, the product name is managed by the product name 912 and the standard name 913, whereas in the product code 1010, the product name is managed by the product name (kanji notation) 1012 and the product name kana (katakana notation) 1013. When creating a product name for the product code 1010, the product name 912 of the product code 910 and the standard name 913 are added to create the product name 1012 of the product code 1010. When creating the product name Kana 1013 of the product code 1010, the product name 912 of the product code 900 and the standard name 913 are added, and then converted to full-width kana. Further, in the product data 900, the price of the product is managed by a unit price (a price per product (unit)) 914, whereas in the product data 1010, the price of the product is lower price (equivalent to cost) 1014 and upper price ( (Corresponding to the unit price) 105, the contents of the unit price 914 of the product data 910 are used when the upper price 1015 of the product data 1010 is created. That is, the unit price 914 and the upper price 1015 are treated as synonyms for abnormal sounds. Note that data that does not exist at the exchange destination, such as the supplier code 015 of the merchandise data 910 and the lower price 914 of the merchandise data 1010, is lost, and data that does not exist at the exchange source needs to be manually supplemented.

FIG. 83 is an automatic data processing process at the time of export / import in data conversion between a plurality of application systems (package software) by the system exchange profile (SXP) service system as a data management system according to the eleventh embodiment of the present invention. It is a data flow figure showing roughly.
In contrast to the above prior art, in the SXP service system according to the eleventh embodiment of the present invention, item definitions (creation of column management tables) as described in the first to tenth embodiments are described for each profile of all types of package software. ) And a standard profile (in the case of FIG. 82, all package software profiles for data management (data items) in order to define the relationship between these profiles. )). Then, using this standard profile, data exchange between different package software is automatically performed (automatic processing) without requiring manual processing. 83, as shown in FIG. 83, for example, in the case of data exchange of the product data 910 and 1010 in FIG. 82, a standard profile for product management that covers data items of product data of all package software ( 83), the various data of the product data 910 is converted into the various data of the product data 1010. For example, the product code 911 of the product data 910 is converted into the product code 1011 of the product data 1010 via the product code 1111 of the standard profile. Further, the product name 912 of the product data 910 is decomposed into kanji and katakana via the product name 1112 and product name kana 1113 of the standard profile to extract the kanji and katakana parts, respectively, and the standard name 913 of the product data 910 is extracted from the standard profile. The product is decomposed into kanji and katakana through the standard name 1114 and the standard name kana 1115 to extract the kanji and katakana parts, respectively, and the product name kana 1113 and the standard name kana 1115 (both are in katakana notation) are added. The data 1010 is converted into a trade name Kana 1013. Further, the unit price 914 of the product data 910 is converted into an upper price 1015 of the product data 1010 via the unit price 1116 of the standard profile. The supplier code 915 of the product data 910 corresponds to the supplier code 1119 of the standard profile, but is deleted because the product data 1010 has no corresponding data item. Further, the lower price 1014 of the product data 1010 corresponds to the cost 1116 of the standard profile, but since there is no corresponding data item in the product data 910, it is left blank (NULL). The product management standard profiles 1111 to 1120 cover data items of product data of all product management package software such as the list price 1118 in addition to the standard data items 1111 and the like. The description of FIGS. 78 to 83 corresponds to the SXP feature 1.

FIG. 84 shows the required system number (necessary mapping number) in the case of data exchange using a standard profile by the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention. It is a data flow figure shown in comparison with the number of required systems (the number of required mapping) in the case of data exchange by.
As shown in FIG. 84 (a), in the case of data exchange with the conventional system configuration, for example, five ordering companies 1201, 1202, 1203, 1204, 1205 and five ordering companies 1211, 1212, 1213, 1214, 1215 When they conduct electronic commerce with each other, a system for five ordering companies corresponding to each ordering company is required, and as a result, 5 × 5 = 25 kinds of systems are required (the law of multiplication). On the other hand, when the SXP service system according to the eleventh embodiment described with reference to FIG. 83 is used, as shown in FIG. 84 (b), the five ordering companies 1201, 1202, 1203, 1204, 1205 are the ordering companies, respectively. If 5 companies 1211, 1212, 1213, 1214, and 1215 conduct electronic commerce with each other via the standard profile 1220, 5 + 5 = 10 systems may be used (the law of addition). That is, in the above example, the system of 25-10 = 15 is unnecessary as compared with the conventional system, and the system investment of 15/25 = 60% is unnecessary. Assuming a transaction of 100 ordering companies and 100 ordering companies, compared to 100 × 100 = 10,000 using the conventional system, 100 companies + 100 companies = 200 companies using the system of the present invention. 9800 / 10,000 = 98% of the system investment can be reduced, and as the number of companies of mutual transactions increases, the reduction effect increases. This reduction effect is generally referred to as an advantage when exchanging data via a standard format when exchanging data between companies or between systems compared to data exchange in its original format. . However, this SXP service system defines a standard format as a standard profile, defines various unique formats as system profiles, and relates information related to data items between the standard profile and each system profile. A major feature is that the conversion information including the conversion method is defined, and these standard profiles, system profiles and conversion definitions are provided as SXP, and this point is compared with the data exchange via the mere standard format described above. It is a big difference. This SXP service system can provide means to exchange data without developing a program or system for accessing the standard profile using such a configuration (SXP), especially using package software. This is an innovative mechanism for small and medium-sized enterprises that do a lot of work. The description with reference to FIG. 84 corresponds to the SXP feature 4.

Next, the features of the SXP service system described with reference to FIG. 84 will be described in more detail with reference to FIG. FIG. 85 shows a data conversion mechanism between a plurality of enterprise systems by a system exchange profile (SXP) service system as a data management system according to the eleventh embodiment of the present invention. It is explanatory drawing demonstrated in comparison with.
Currently, various industry standard XMLs have been proposed for the purpose of facilitating or improving data management and data usage within the industry. For example, XBRL (extensive business reporting language) data as standard XML data related to financial information, ebXML (electric business XML) data as standard XML data related to electronic commerce, MML (medical data) as standard XML data related to medical information Etc. have been proposed. Then, for example, in order to convert the unique data of one company into the unique data of another company using the industry standard XML data 1220, as shown in FIG. A conversion system that converts data to standard XML 1220 is used. That is, when data is exchanged between A company 1230 and B company 1240, first, A company 1230 and B company use their own conversion system 1231 and conversion system 1241 to create their own data according to their own format. Company A's original data 1232 and Company B's original data 1242 are converted into standard XML data in accordance with the specifications and rules of the industry standard XML (such as DTD and XML schema), and Company A conversion standard XML data 1233 and Company B conversion standard XML Each data is converted into data 1243. The company A 1230 and the company B 1240 exchange data using the company A conversion standard XML data 1233 and the company B conversion standard XML data 1243. The company A 1230 and the company B 1240 convert the company B conversion standard XML data 1243 and the company A conversion standard XML data 1233, which are the XML standard data of the other party that exchanged the data, into the conversion system 1231 and the conversion system 1241 for the company. Are converted into company A's own data 1232 and company B's own data 1242, which are its own data. In this way, each company needs to develop and prepare its own conversion program and conversion system for data exchange between the original data in its own format and the standard XML data in the standard format.

  On the other hand, as shown in FIG. 85B, the SXP service system has a standard profile (SXP standard profile) 1250 that defines a standard format for each industry and a unique format that defines a unique format for each company belonging to the industry. Conversion definition that defines conversion rules between data profiles (company A unique data profile 1252, company B unique data profile 1262,...), And SXP standard profile 1250 and each company's unique data profiles 1252, 1262. 1251, 1261,..., SXP standard profile 1250, each company's own data profile 1252, 1262... And conversion definition 1251, 1261. PXE (Profile eXcha And a ge Engine) data conversion system 1253. The SXP standard profile 1250 corresponds to the EDI standard data profile (standard data item definition part of the column management table) of the above embodiment, and various industry standard data formats are used for data exchange of various business systems. Stores definition information corresponding to. In addition, each company's unique data profile 1252, 1262... Corresponds to the company-specific data profile for EDI of the above embodiment (company-specific data item definition portion of the column management table) and corresponds to each company belonging to various industries. Stores definition information corresponding to the original data format. Further, the conversion definitions 1251, 1261... Correspond to the EDI item relation definitions in the above embodiment. In the SXP service system, for example, when data exchange is performed between the company A 1230 and the company B 1240, the PXE data conversion system 1253 uses the company A unique data 1232 and the company B unique data 1242 to correspond to the company A. A unique data profile 1252 and a B company unique data profile 1262 are determined, respectively, and a conversion definition 1251 and a conversion definition 1261 corresponding to the A company unique data profile 1252 and the B company unique data profile 1262 are used, respectively. 1232 and the B company unique data 1242 are converted into SXP standard format data according to the SXP standard profile, respectively, and the data exchange between the A company 1230 and the B company 1240 using the SXP standard format data is enabled. In the SXP service system, the PXE data conversion system 1253 receives from the B company 1240 and the A company 1230 by using the A company unique data profile 1252 and the B company unique data profile 1262, the conversion definition 1251, and the conversion definition 1261, respectively. The converted SXP standard format data is converted into A company unique data 1232 and B company unique data 1242, respectively. Thus, according to the SXP service system, each company develops and prepares its own conversion program and conversion system for data exchange between the original data in its own format and the standard XML data in the standard format. There is no need, as long as you prepare your own data with an existing simple system such as package software, using the unique data profile and conversion definition corresponding to the data format, data conversion to SXP standard profile data, Data exchange with other companies using the SXP standard profile data can be realized easily and at low cost, and data can be easily converted into proprietary format or data of other company's format using the SXP standard profile data. Can be realized at low cost Kill.

FIG. 86 exemplifies data structures and file configurations (table related) of various industries, various systems, and various package software used in the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention. It is a data structure figure.
The management target data of the SXP service system is data of any arbitrary data format. For example, as shown in the left column to the right column of FIG. 86, company master data (leftmost column), product master data (2 from the left) (Second column), etc., any master data used in any system of any business, sales data (center column), purchase data (second column from the right), accounting data (rightmost column) For example, any transaction data used in any system for any business is a management target. As described above, the SXP service system basically has the same configuration as the data management system for electronic commerce (Embodiment 4 and Embodiment 5), while the management target data is all related to all business contents. A general-purpose data management system that spans data formats. Therefore, the SXP service system as the data management system according to the eleventh embodiment is adapted to the data management system (implementation) so that it can flexibly cope with the difference or change in the configuration of the business to be managed and the system (including the data format) The system configuration of the fourth embodiment, the fifth embodiment, or the like) is changed, for example, a part of the table is XML, and the degree of correspondence to the business and the system is increased. The SXP service system manages data in a hierarchical structure such as a target system, each table (in the case of RDB) and each file (in the case of another DB) in the target system, and each record in the table / file.

FIG. 87 is a table showing a list of databases used in the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention.
The table structure of the database used in this SXP system will be described. The database used in the SXP system uses a combination of the original table of the relational database (RDB) and the table (XML table) obtained by converting the RDB table (RDB table) into an XML format as shown in FIG. Various RDB tables and various XML conversion tables are provided as data structures and definition structures. More specifically, first, the company management (CUSTOMER) table includes various types of information on companies that use the system (including packages) targeted by the SXP service system and user companies of the SXP service system, for example, the top of FIG. It is an RDB table for managing company information such as company information shown in the left column. The company management table has a configuration corresponding to the company management table of FIG. 36 in the data management system of the fifth embodiment. Next, the event management (EVENT) table is an XML table for managing events of data types exchanged between companies, that is, events of data linkage between systems. The event management table has a configuration corresponding to the data exchange management (EXCHANGE) table of FIG. 37 in the data management system of the fifth embodiment, and further specifies a transmission side system and a reception side system in data exchange. Data items for XML conversion, such as a transmission system tag name, a reception system tag name, and an event tag name for specifying a target event, are added, and corresponding data item values are stored. The event management table further stores a corresponding data item value by adding a data item (“event attribute”) indicating the type of data conversion. Here, the event management table includes not only the data conversion limited to the ordering / ordering data as in the data management system of the fourth embodiment by the PXE data conversion system 1253 which is the core engine of the SXP service system 1250, but also any data. In order to support data conversion and data exchange between all systems, the data exchange management (EXCHANGE) table is replaced with this SXP service system. In addition, the event management table handles all data that can be assumed in response to the fact that this SXP service system is a so-called message-driven system that is activated by receiving exchanged data as a message. Definition (data item) is set. Normally, the basis of data linkage in this SXP service system is configured to convert data in a predetermined data format of a message-driven single table into data of another data format and store it in another single table. Event. However, in the data linkage in the SXP service system, data of a plurality of tables (pre-conversion table group) may be simultaneously converted into data of a plurality of other tables (conversion destination table group). Therefore, in the present SXP service system, with respect to various events in such a case, how to link the pre-conversion table group with the conversion destination table group is defined in the event management table. For example, in accordance with the definition of the data exchange management table of the fifth embodiment, for example, in ordering business, a file header table for storing file header information, a slip header table for storing slip header information, and slip details When a plurality of tables such as a slip detail table to be stored are converted at the same time, the conversion process is defined in the event definition table as an “order received” event.

  Next, the table management (TABLE) table is an XML table that manages various tables and records for each data type for each company and each system. The table management table has a configuration corresponding to the table management (TABEL) table of FIG. 39 in the data management system of the fifth embodiment, and further specifies the system tag name and the table in the target system (or Further, data items for XML conversion, such as table tag names for specifying the input / output classification of the table and the table structure of the table, are added, and the corresponding data item values are stored. The table management table manages information and data of each table in every system (including package software) targeted by this SXP service system in units of each system. In addition, when the table to be converted is composed of a plurality of target tables, the table management table further adds a data item indicating the order (such as “table branch number”) and stores the corresponding data item value. Yes. Note that the table management table corresponds to the structure of the table tag name, etc., data items ("table structure" etc.) that define information for specifying the table structure, and table input / output classification (for import, A data item (such as “table attribute”) defining information for specifying (for export, sharing, etc.) may be further added to store the corresponding data item value.

  Next, the column management (COLUMN) table is an XML table for managing attributes, positions, lengths, and the like of the respective data items constituting each table (each record) targeted by the table management table. The column management table has a configuration corresponding to the column management table of FIGS. 40 to 42 in the data management system of the fifth embodiment, and in addition to the system tag name, the table tag name, and the table branch number, Data items for XML conversion, such as item tag names for specifying the data items of each record, are added and corresponding data item values are stored. That is, the column management table defines the data format of each management target data. Next, the item value management (COLUMN_VALUE) table indicates the value stored in each data item and the corresponding semantic content when the conversion of the value and the content is required among the data items defined in the column management table. This is an XML table to be managed. The item value management table has a configuration corresponding to the item value management table of FIG. 43 in the data management system of the fifth embodiment, and further includes the system tag name, the table tag name, the table branch number, and the item. Data items for XML conversion, such as tag names, are added and corresponding data item values are stored.

  Next, the row management (ROW) table is an RDB table that stores record unit identifiers of data read for data exchange and predetermined basic data. In the row management table, a new record (a record of the row management table itself consisting of the identifier etc.) is created for each read (stored) record. The row management table has a configuration corresponding to the row management table of FIG. 47 in the data management system of the fifth embodiment. In addition, the row management table adds data items such as the system tag name and table tag name corresponding to the configuration of the XML table management table and the like, and further, identifier tags corresponding to the stored identifiers. Names are added as data items, and corresponding data item values are stored respectively. In addition, basic data (data items) stored in the row management table may be a transmission company code, a reception company code, and the like. The row management table stores identifiers (information corresponding to rows in the spreadsheet system) stored in the SXP service system. A row ID (ROW_ID) indicating whether the record is a key item is stored as a key item.

  Next, the value management (CELL) table stores the data item value of the input data at the time of data exchange in the cell uniquely indicated by the row ID of the row management table and the column ID of the column management table. It is a table. The value management table has a configuration corresponding to the value management table of FIG. 48 in the data management system of the fifth embodiment. In addition, the value management table stores corresponding data item values by adding data items such as item tag names corresponding to the data item values to be stored, corresponding to the XML conversion of the SXP service system. As described in the above embodiment, the value management table can also store the contents of one record.

  Next, the item relation definition (COLUMN_CHAIN) table is an XML table that manages relation definition (link) information between data items defined and managed in the column management table (of different data profiles). The item relation definition table basically has a configuration corresponding to the item relation definition table of FIG. 44 in the data management system of the fifth embodiment, but the table management table and the column management table are converted into XML, The configuration corresponds to the configuration of the XML event management table. That is, the item relation definition table includes, as data items, a chain ID (CHAIN_ID) that is a management number that uniquely indicates each item relevant information, the transmission system tag name, the reception system tag name, the event tag name, XML that indicates a table that is an event attribute, a processing group (EVENT_GROUP) indicating a processing order of a plurality of processing groups in the event, a processing order (EVENT_SEQ) indicating a processing order of a plurality of subgroups in the event, and a trigger (conversion source) Trigger table tag that is a tag name (TRIGGER_TABLE_TAG), XML tag name that is an XML tag name that indicates a trigger data item (TRIGGER_COLUMN_TAG), and XML tag name that indicates a table that is a conversion target (conversion destination) Elephant table tag (MAIN_TABLE_TAG), target item tag (MAIN_COLUMN_TAG) which is an XML tag name indicating a data item to be converted, a code (FUNCTION_CODE: refer to a function table described later) indicating a function used for item related information, It has a parameter (PARAM) indicating a parameter area to be used, and stores a corresponding data item value. As described above, the item relation definition table manages relation information between the data items defined in the column management table. That is, the item management table stores a trigger data item and a data item to be converted in association with each other, and manages a function to be used again and a parameter for converting the data item value between the data items. ing. In principle, as in the above embodiment, each data item of the system profile is selected and stored in the trigger item, and each data item of the standard profile is selected and stored in the target item. As a result, for each event defined in the event management table, data conversion is realized between each data item of the conversion source system profile and the data item of the conversion destination system profile via each data item of the standard profile. To do.

  Next, the function management (FUNCTION) table is an XML table that manages system functions used in the item relation definition table. The function management table has a configuration corresponding to the function management table of FIG. 45 in the data management system of the fifth embodiment. Next, the storage area management (VOLUME) table is an RDB table that manages a storage area of a database that stores various data input and output by the SXP service system. The stored breath management table manages the storage area by target company, year, etc. Next, the company-specific storage area management (VOLUME_CUSTOMER) table is an RDB table that manages companies to be converted into data in units of created volumes. The system management (SYSTEM) table is an RDB table for managing system information for each user of the SXP service system, and manages user keys and the like. Next, the work management (TRANSACTION) table is an RDB table for managing data conversion work of the SXP service system for each transaction, and manages one transaction as one input file. Next, the object management (SYSTEM_OBJECT) table is an RDB table that manages objects targeted by the SXP service system, and manages objects such as slips, packing, and payment contents. The target management table has a configuration corresponding to the target management table of FIG. 46 in the data management system of the fifth embodiment. Next, the input / output management (FORM) table is an XML table for managing screens and forms. The input / output management table has a configuration corresponding to the input / output management tables of FIGS. 56 and 59 in the data management system of the fifth embodiment. Next, the input / output item management (FORM_COLUMN) table is an XML table for managing the size and position of data items to be input / output on a screen or a form. The input / output item management table has a configuration corresponding to the input / output item management table of FIGS. 55 and 58 in the data management system of the fifth embodiment. Next, the key management (KEY) table is an RDB table that stores values that are keys of stored records. The key management table is a comparison table with the target management table. The key management table stores information corresponding to index keys, external reference keys, and identifiers of records stored in the SXP service system, and is used for searching and maintaining relationships between stored records. .

  Note that the configuration (data items) of each table can be changed as appropriate without departing from the spirit of the SXP service system.

FIG. 88 shows data exchange processing between different application systems (package software) using a standard profile (general-purpose product profile) by a system exchange profile (SXP) service system as a data management system according to the eleventh embodiment of the present invention. It is a data flow figure showing an outline.
FIG. 88 explains the system configuration of FIG. 83 in more detail. As shown in FIG. 88, the product data 910 of the package A has a unique data item definition 1310 including a product code 911, a product name 912, a standard name 913, a unit price 914, and a supplier code 915 as described above. ing. Further, the product data 1010 of the package B has a unique data item definition 1310 including a product code 1011, a product name 1012, a product name Kana 1013, a lower price 1014, and an upper price 1015 (for convenience, the data items of both packages Definitions are displayed with the same part number, but each package has its own data item definition). The data item definition 1310 unique to the package A and the data item definition 1310 unique to the package B are items in the product management column management table (not shown) as in the first to tenth embodiments. Stored as part of the definition information. Note that data item definitions unique to other (all) package software (not shown) are all stored as part of the item definition information in the column management table for product management. In other words, the data item definition (sometimes simply referred to as “item definition”) in the present embodiment refers to information that defines data items included in each of the enterprise system> package software> files. Furthermore, the general-purpose product profile 1330 as the standard profile for product management includes the product code 1111, the product name 1112, the product name Kana 1113, the standard name 1114, the standard name Kana 1115, the cost 1116, the unit price 1117, the list price 1118, the specifications as described above. Data items that cover item definitions of all existing package software, such as entry codes 1119,... 1120, are defined. And this general-purpose product profile is also stored in the column management table as in the first to tenth embodiments. Note that the general-purpose product profile defines general-purpose data of product information handled by a company, but does not have related definition information because it is a standard profile. Related definition information is included in the definition of each system profile related to a standard profile such as the general-purpose product profile, and is SXP.

  On the other hand, in the SXP service system, in the same way as the data exchange using the item relation definition table of the first to tenth embodiments, the data item of the package A (the item definition 1310 of the item definition 1310) defined in the column management definition table. Each definition item (mapping information) 1320 between each data item) and the data item of the general-purpose product profile 1330 is defined in advance, and the data item of the package B (item definition 1310 each item is defined in the column management definition table 1330) The relationship definition information (mapping information) 1320 between the data item) and the data item of the general-purpose product profile 1330 is defined in advance. That is, in the present embodiment, the relationship definition between the data items unique to each package software and the data items of the general-purpose product profile is the item relationship definition table for product management (illustrated) as in the first to 10th embodiments. Is stored as item related definition information. As described above, the item relation definition table for managing the relation definition information according to the present embodiment defines the relation between the data items of each package software defined in the column definition table and the standard data items of the general-purpose product profile. . In the present embodiment, the two definition information of the item definition and the related definition are collectively referred to as a system profile. Thereby, data exchange between each data item of the data item definition 1310 of the product data 910 of the package A and each data item of the data item definition 1310 of the product data 1010 of the package B is performed via the general-purpose product profile 1330. It becomes possible. The description with reference to FIG. 85 corresponds to the SXP feature 2.

Embodiment 12
FIG. 89 is a data flow diagram showing an overview of a system profile distribution service system by a system exchange profile (SXP) service system as a data management system according to the twelfth embodiment of the present invention.
As shown in FIG. 89, the SXP support center (center side server system) 1400 includes an SXP (system exchange profile) 1401 which is a system profile (item definition and related definition) unique to the A package, and a system profile (items) unique to the B package. SXP (system exchange profile) 1402 which is a definition and related definition), SXP (system exchange profile) 1403 which is a system profile (item definition and related definition) unique to the C package, and a system profile (item definition and related definition) specific to the D package ) SXP (System Exchange Profile) 1404, SXP (System Exchange Profile) which is a system profile (item definition and related definition) unique to E package Yl) 1405 stores and manages SXP different types of packages of ... and the like. The SXP support center 1400 also includes a PXE (Profile Exchange Engine) 1406 serving as an engine for exchanging data between SXPs of each package. On the other hand, the SXP user (user side client system) 1410 includes a PXE 1406 similar to the SXP support center 1400. Then, the SXP user 1410 downloads the SXP of any package software that is being used by the SXP support center 1400 and needs data exchange via the network NT such as the Internet, and the PXE 1406 transmits the package software between the package software. To exchange data (export data import process). For example, when the SXP user 1410 exchanges data between desired packages, for example, between the package A 900 and the package B 1000, the SXP 1401 of the A package and the SXP 1402 of the B package are downloaded from the SXP support center 1400, and the PXE 1406 is downloaded. Thus, using the item definition and related definition of SXP1401 and the item definition and related definition of SXP1402, data exchange processing for importing export data between package A900 and package B1000 is executed. As described above, the SXP service system according to the present embodiment realizes a function as a distribution service system of the system profile (SXP) of each package. The description with reference to FIG. 86 corresponds to the SXP feature 3.

Embodiment 13
FIG. 90 shows creation and distribution processing of an industry system profile by a system exchange profile (SXP) service system as a data management system according to the thirteenth embodiment of the present invention, and creation of a package system profile by a package development vendor in the industry. FIG. 5 is a data flow diagram showing an overview of distribution processing and association definition processing between the industry system profile and the package system profile.
As shown in FIG. 90, the SXP support center 1400 corresponds to the handling data items and format (profile) information unique to each industry in addition to the SXPs 1401 to 1405 of the respective packages as described above in the eleventh embodiment. Thus, an industry standard SXP (system exchange profile) is stored and managed as a unique system profile (item definition and related definition) created to enable data exchange between different systems of each industry company. For example, the SXP support center 1400 stores and manages a industry standard SXP 1409, b industry standard SXP 1408, c industry standard SXP 1407,. This industry standard system profile consists of item definition information in which each company profile information that defines data items unique to each company's system and standard profiles that cover all data items handled in the industry are defined in the column management table. Item relation definition information in which the item relation definition with the standard profile is defined in the item relation definition table is prepared by the industry group 1420 and the like. For example, the a industry group 1420 creates the a industry standard SXP 1409 based on the a industry standard message 1421 formulated by itself, as indicated by an arrow with a circled number 1 in FIG. Then, the a industry group 1420 uploads the created a industry standard SXP 1409 to the SXP support center 1400 via a network such as the Internet NT, as indicated by an arrow with a circled number 2 in FIG. For other industries (b industry, c industry...), An industry group (b industry group, c industry group...) 1420 similarly uses the industry standard SXP (b industry Standard SXP 1408, c industry standard SXP 1407, etc.) are created and uploaded to the SXP support center 1400.

  On the other hand, a package vendor developing package software corresponding to each industry creates a package software-specific package SXP (similar to that described in the eleventh embodiment) and develops the package software for the desired industry. When developing the package software, the item-related definition is defined between the industry standard SXP of the industry and the package SXP unique to the company's package software, and is also uploaded to the SXP support center 1400. For example, the E package development vendor 1430 that developed the E package 1431, as indicated by the circled arrow 3 in FIG. 90, from the SXP support center 1400, the a industry of the a industry to which the assumed user of the developed E package 1431 belongs. Download standard SXP1409. Next, the E package development vendor 1430 changes the item definition of the SXP 1405 of the E package 1431 from the export / import format (EX / IN format) of the developed E package 1431 as indicated by an arrow with a circled number 4 in FIG. Next, as shown by the circled arrow 5 in FIG. 90, an item relation definition between the item definition of the SXP 1405 of the E package 1431 and the item definition of the downloaded a industry standard SXP 1409 is performed. Next, the E package development vendor 1430 uploads the SXP 1405 of the completed E package 1431 to the SXP support center 1400, as indicated by the arrow with the circled number 6 in FIG. In this way, the industry standard SXP of each industry is stored in the SXP support center 1400 and is updated and managed as necessary (by each industry itself). Package SXP unique to development package software in which the item-related definition with the industry standard SXP of the industry has been completed by the package vendor developing the corresponding package software (similar to that described in the eleventh embodiment) ) Is stored, and is updated and managed as necessary (by each development vendor itself). The description with reference to FIG. 90 corresponds to the SXP features 7, 8, and 9.

Embodiment 14
Hereinafter, the SXP service system according to the fourteenth embodiment of the present invention will be described. First, the background art of the SXP service system according to the fourteenth embodiment will be described with reference to FIGS. FIG. 91 is a data flow diagram schematically showing the relationship between the business flow of a conventional small business and electronic data exchange (EDI).
FIG. 91 shows the relationship between the business flow of SMEs and EDI (electronic data exchange). As shown in FIG. 91, for example, it is assumed that a certain company performs management using sales management software 1500, distribution / production management software 1510, purchase management software 1520, and accounting management software 1530. In this case, when an order receiving operation occurs through a request for a product estimate, a sales manager (such as a sales department) first inputs the estimate data 1501 using the sales management software 1500. Then, the order data 1502 is created from the estimate data 1501 in accordance with the order. Next, the order data 1502 is input to the distribution / production management software 1510 by a distribution / production management person (production department or the like). At this time, the person in charge exports the order data 1502 from the order management software 1500, converts it into a CSV file, etc., performs predetermined data processing on the CSV file as described above, and then processes the processed data. Is imported into the logistics / production management software 1510. Then, the distribution / production management software 1510 sequentially creates delivery date reply data 1511 and shipping instruction / production instruction data 1512 based on the input data. In addition, the distribution / production management software 1510 sequentially creates the delivery data 1513 and the packing / shipping data 1514 from the shipping instruction / production instruction data 1512 when the production of the ordered product is not necessary (when the goods are purchased from the outside). To do. On the other hand, the distribution / production management software 1510 sequentially creates the parts procurement data 1515 and the production data 1516 from the shipping instruction / production instruction data 1512 when the production of the ordered product is necessary. Create the shipment data 1514 sequentially. In these data inputs, there are cases where some manual intervention is required (partial manual input is required).

  Here, when purchasing a product from outside, the delivery data 1513 is input to the purchase management software 1520 by a purchaser (purchasing department or the like). At this time, the person in charge exports the outgoing data 1513 from the logistics / production management software 1510 and converts it into a CSV file, etc., and after performing predetermined data processing operations on the CSV file etc. as described above, Are imported into the purchase management software 1520. Then, the purchase management software 1520 sequentially creates order data 1521, receipt data 1522, receipt data 1523, payment data 1524, and withdrawal data 1525 based on the input data. In these data inputs, there are cases where some manual intervention is required (partial manual input is required). On the other hand, the packing / shipping data 1514 from the distribution / production management software 1510 is input to the sales management software 1500 again by the person in charge. At this time, the person in charge exports the packing / shipping data 1514 from the logistics / production management software 1510 and converts it into a CSV file, etc., and after performing predetermined data processing operations on the CSV file etc. as described above, The processed data is imported into the sales management management software 1500. Then, the sales management software sequentially creates sales data 1503, monthly closing process data 1504, billing data 1505, and deposit data 1506 based on the input data. In these data inputs, there are cases where some manual intervention is required (partial manual input is required). In general, the accounting management software 1530 is independent from the input / output of each of the software 1500, 1510, and 1520, and an accounting person (accounting department or the like) inputs necessary accounting data and financial management data 1531. And deposit / withdrawal management data 1532 and the like are created.

A conventional problem related to the accounting data will be described. FIG. 92 is a data flow diagram schematically showing an aspect of data management by the conventional package software for small and medium enterprises.
As shown in FIG. 92, as the package software introduced by the small and medium enterprise, the sales management software 1500, the purchase management software 1520, and the conference management software 1530 as described in FIG. 91 are representative. In this case, the sales manager 1507 operates the sales management software 1500 to perform input / output, and outputs the accounts receivable data 1508 as accounting data. In addition, the purchase management person 1526 operates the input management software 1520 to input / output, and outputs the accounts payable data 1527 as the accounting data. The accounting manager 1550 in the accounting department manually creates a slip (payment slip) from the accounts receivable data 1508 and manually creates a slip (withdrawal slip) from the payable data 1528. Data (payment / withdrawal data) is manually entered into the accounting management software 1530. Then, the accounting management software 1530 creates the financial data 1530 from the input data, outputs financial statements such as a balance sheet and profit and loss statement, etc., and external financial and accounting reports, management information, etc. Served for use. As a first problem at this time, the accounts receivable data 1508 handled by the accounting department is re-input manually, so there is a possibility that it does not necessarily match the actual accounts receivable data 1508 (sales data). Further, as a second problem, since the accounts payable data handled by the accounting department is again re-input manually, there is a possibility that the actual accounts payable data (purchase data) does not always match. Furthermore, as a third problem, the accounts receivable / accounts handled by the accounting department are rounded (adjusted) as accounting operations, and the relationship with the original detailed sales / purchase data is divided. there is a possibility. Therefore, there is a possibility that the data obtained from the relationship management software 1530 can be settled but cannot be effective data for management analysis.

FIG. 93 is a data flow diagram schematically showing the relationship between a conventional electronic data exchange (EDI) and an existing system, taking as an example an order processing job.
FIG. 93 shows the data exchange operation of FIG. 92 only in the case of information unique to the order receiving work, that is, information processing of sales management software 1500 and information processing of distribution / production management software 1510. As shown in FIG. 93, an estimate 1501a is issued with the creation of the estimate data 1501 of the sales management software 1500, and an invoice 1503a is issued with the creation of the sales data 1503. In addition, an instruction sheet 1512a is issued with the creation of the shipping instruction / production instruction data 1512 of the distribution / production management software 1510, and a packing label 1514a and an invoice 1514b are issued with the generation of the packing / shipping data 1514. .

FIG. 94 is a data flow diagram showing an outline of the usage form of data exchange processing by the conventional package software for small and medium enterprises.
As shown in FIG. 94, as a usage form (usage scene) of data exchange processing by the conventional package software for small and medium-sized enterprises, as shown in FIG. 94, a person in charge of electronic commerce 1561 can provide customer information and information on web shops and electronic markets (EC) 1560 It is conceivable that product information is collected from cart data (purchase data) 1711, 1712, 1713, 1714, 1715. Further, a sales manager 1507 collects transaction information (sales management information) with external companies (business partners) 1701, 1702, 1703, 1704... Using the sales management software 1500, and accumulates and uses it. It is possible to do. Similarly, a purchase management person 1526 uses the purchase management software 1520 to collect transaction information (purchase management information) with external companies (suppliers) 1701, 1702, 1703, 1704. Therefore, it is possible to accumulate and utilize it. Further, the sales manager 1507 and the purchase manager 1526 use the sales management software 1500 and the purchase management software 1520 to obtain related information (sales related information) from the information collected and accumulated by the electronic commerce manager 1561. It is also possible to extract and utilize information related to purchase and purchase). On the other hand, the accounting manager 1535 uses the accounting management software 1530 to independently collect the accounting data, and the sales manager 1507 and the purchase manager 1526 use the sales management software 1500 and the purchase management software 1520. It is also possible to extract and utilize related information (accounting related information) from information collected and accumulated using it. In addition, when inputting / outputting the sales management software 1500 and the purchase management software 1520, the product management data 1600, the shipment management data 1610, the inventory management data 1630, the customer data 1640, and the arrival management data 1650 are referred to. As a conventional problem associated with these various data exchanges, the first problem is that original data (unified management) is used for data exchange with external companies such as business partners in sales management and suppliers in purchase management. Data) needs to be accumulated. In addition, as a second problem, it can be said that accumulation of original data is unnecessary for data exchange with an already installed package, but in this case, as described above, data reference is divided and data exchange source and data exchange destination There is a possibility that problems such as data inconsistency occur. Furthermore, as a third problem, if the data management system as in the first to tenth embodiments is used for exchanging these data, the above problem can be solved. Native data (primary data) will be used, and there is a possibility that considerable processing capability is required for data matching. Therefore, when the data management system as in the first to tenth embodiments is used for exchanging these data, it is considered preferable to cope by storing the data in the XML format. From these viewpoints, as described in detail in the following fourteenth embodiment, the present invention provides an SXP service system in which the data management system of the first to tenth embodiments is further improved to provide versatility. Is. The description of FIGS. 91 to 94 corresponds to the SXP feature 1 described above.

FIG. 95 is an explanatory diagram showing an outline of the overall configuration of a system exchange profile (SXP) service system as a data management system according to the fourteenth embodiment of the present invention.
As shown in FIG. 95, the SXP service system according to the fourteenth embodiment is centered on the SXP center 1810 (same configuration as the SXP support center 1400 of the thirteenth embodiment), and the standard profile system 1800, enterprise profile system. It has a package deployment concept consisting of 1820 and profile user system 1830. Specifically, the SXP center 1810 implements functions such as a profile management function, a data conversion function, and a data storage function by using a column management table, an item relation definition table, a data conversion engine (PXE), and the like. The standard profile system 1800 is a system that manages various standard profiles such as the general-purpose product profile and the industry standard profile (industry standard SXP), such as an electronic commerce (EC) function, a communication environment providing function, an ordering / ordering management function, and the like. Each function is realized. On the other hand, the company profile system 1820 is a system that implements functions such as a product management function, a customer management function, and an inventory management function based on a company-specific profile. Note that each standard profile of the standard profile system 1800 and each company profile of the company profile system 1820 are managed by profile management function implementation means (column management table, item related definition table, etc.) of the SXP center 1810. In addition, the profile user system 1830 allows a user such as a small and medium-sized company that performs management such as sales management, payment management, and financial management using various package softwares to receive the company profile of the company profile system 1820 via the SXP center 1810. And a standard profile corresponding to the standard profile system 1800, a data exchange function between package software used in-house is realized without requiring manual processing. The description of FIG. 92 corresponds to the SXP feature 2.

FIG. 96 is a schematic configuration diagram of classes for processing a system profile of a system exchange profile (SXP) service system as a data management system according to the fourteenth embodiment of the present invention.
The SXP service system according to the fourteenth embodiment performs processing by storing the definitions of system profiles (item definitions and item-related definitions) in the class shown in FIG. Specifically, the system profile 1900 of the fourteenth embodiment has a table class 1910, a table join class 1920, an event class 1930, and a chain class 1940. The table (Table) class 1910 defines each table, and has a column definition (Column) class 1910 and an index definition (Index) class 1920 as subclasses. Based on the column definition class 1911, a column management table is created by removing the index definition from the column management table of the first to tenth embodiments. In addition, based on the index definition class 1912, an index table is created by extracting indexes (TranID, slip No. product ID, supplier ID, etc.) of the column management table of Embodiments 1 to 10 and defining them separately. . A table join class 1920 defines relations between tables, and includes sub-classes a connected column definition (JoinColumn) class 1921 and a connected type (JoinKind) class 1922. Based on the concatenated column definition class 1921, information that defines the concatenation relationship or hierarchical relationship between tables (information corresponding to the branch number that is the definition information of the hierarchical relationship in the column management table of the first to tenth embodiments) is stored. A concatenated column definition table is created. The event class 1930 defines an event determined by input and output, and has a data source definition (DataSource) class 1931 and a procedure definition (Procedure) class 1932 as subclasses. A chain class 1940 defines a relation between items and a conversion process executed for each relation definition. As a subclass, an item relation definition (Chain) class 1941, a function definition (Function) ) Class 1942. Based on the item relation definition class 1941, an item relation definition table similar to the item relation definition table of the first to tenth embodiments is created. Also, based on the function definition class 1942, a function definition table similar to the function management table of the first to tenth embodiments is created. As a class (class used in the procedure) related to the procedure definition (Procedure) class 1932, a procedure type (ProcedureType) class 1933, an input data source (InputDataSource) class 1934, an output data source (OutputDataSource) class 1935, a chain definition A (Chain) class 1936, an input data work area (InputDataWorkspace) class 1937, and an output data work area (OutputDataWorkspace) class 1938 are included.

FIG. 97 is a data flow diagram showing an outline of data conversion processing by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
As shown in FIG. 97, the conversion system 20000 (data exchange engine (PXE) having system profile 1900) of the SXP service system of the fourteenth embodiment executes the following procedure (process) as the conversion and exchange procedure. First, as a first procedure (STEP 1), as shown by a circled number 1 in FIG. 97, the processing flow 2100 is started with the input of the input data 2001 as an event. Next, as a second procedure (STEP 2), as indicated by a circled number 2 in FIG. 97, as a pre-procedure execution process, the input data source 1934 is analyzed and a matching input profile is referred to, and data check is performed. Do. Next, as a third procedure (STEP 3), a data source that can be converted from the input data source 1934 is determined, an event name of the event 1930 is determined, and processing of the procedure 1932 group of the determined event 1930 is executed. At this time, output data sources 1935 that can be converted and exchanged are determined, and if there are a plurality of output data sources 1935 that can be converted and exchanged, parallel processing is performed. Next, as a fourth procedure (STEP 4), as indicated by a circled number 3 in FIG. 97, the data of the input data source 934 is fetched and read into the input workspace 2120 in accordance with the input profile definition. Next, as a fifth procedure (STEP 5), as shown by a circled number 4 in FIG. 97, data conversion and exchange are executed by a chain processing execution module 2230 using a chain class 1940, Data is created in the output workspace 2240. Here, when data other than the input / output data source is generated, the data is stored in the temporary work space 223. Next, as a sixth procedure (STEP 6), the data in the output workspace 2240 is written as the output data source 1935 according to the output profile definition, as indicated by the circled numeral 5 in FIG. Accordingly, the row management table (corresponding to the row management table in the above embodiment) 224 and the item value management table (corresponding to the item value management table in the above embodiment) 224, the row management table 212, and the item corresponding to the input data A value management table 212 is created. Next, as the seventh procedure (STEP 7), as indicated by the circled number 6 in FIG. 97, the processing of STEP 4 to STEP 6 (processing of the circled numbers 3 to 5) until the end of all records of the input data source 1934 is completed. repeat. Next, as the eighth procedure (STEP 8), as shown by the circled numeral 7 in FIG. 97, post-procedure execution processing such as storage processing of conversion and exchange processing results, initial processing of input / output workspaces, etc. is executed. Finally, output data 2002 is obtained.

Specifically, the SXP service system according to the fourteenth embodiment has the following classes as class definitions.
Object: Class that manages an instance of an EDITY object ObjectType: Object type Source Type: Data source type Data Type: Column data type Procedure Type: Procedure type Function Type: Object type List: Manages all objects , Which enables object access by tag name, Profile: class that constitutes profile Table: class that constitutes table definition Column: class that constitutes column definition of table Complex Column: class that constitutes composite column definition of table Index: table Class Join that defines the index and primary key of the table : Class that configures connection information between tables Event: Class that configures event definitions Procedure: Class that configures input / output and chain cuts Chain: Class that configures data chains between tables Function: One processing unit of a data chain Constructing class Data Source: Class defining connection information with input / output data Workspace: Temporary storage of input data during execution of procedure The class Row: Class that holds 1 record data of Table in Workspace: Cell 1 of Row Class that holds column data Sys: A class that holds all objects Engine: A class that provides an interface with the outside to provide resources

Further, the SXP service system according to the fourteenth embodiment provides the following functions in detail.

NOP: NOP
Let: substitution A = B;
PLet: parameter substitution A = P1;
Format: Format A = Format (B, P1); B is converted into the format of P1, and output Add: Addition A = B + P1;
Sub: Subtraction A = B-P1;
Mul: Multiplication A = B * P1;
Div: division A = B / P1
Insert: Insert character string A = Insert (B, P1, P2); Insert P2 at position P1 of B Concat: Concatenate character string A = Concat (B, P1, P2,...); B, P1, P,. Remove: Character string deletion A = Remove (B, P1, P2); Delete the number of characters P2 from the position P1 of B Substring: Get partial character string A = Substring (B, P1, P2); The number of characters of P2 is acquired from the position. Sum: Total A = Sum (B); B total value Max: Maximum A = Max (B); B maximum value Min: Minimum A = Min (B); B minimum value Avg : Average A = Avg (B); Average value of B Count: Count A = Count (B); Count number of B data Sequence: Sequence A = Sequence ( ); Record serial number Iif: conditional expression IF A = Iif (B, P1, P2, P3, P4); B and P1 are compared with the conditional expression of P2, if true, P3, if false Outputs P4 Case: Conditional expression CASE A = Case (B, P1); Outputs the output value of the comparison value that matches B from the data string (comparison value, output value) of P1 IsNull: Null data determination A = IsNull ( B); “true” is output in the case of null data IsNumeric: numeric data determination A = IsNumeric (B); “true” is output in the case of numerical data IsDate: date data determination A = IsDate (B); Output “Goto”: Conditional branch A = Goto (B, P1, P2, P3); The values of B and P1 are compared with the conditional expression of P2, and the result is output.
Call: Call A = Call (P1); Call the chain specified by P1, and output the result.
End: End processing A = End (B, P1); Chain B with B as the end result and P1 as the end content.
Object: Set the default object

FIG. 98 is an explanatory diagram showing an outline of the connection / correspondence relationship between tables by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
The SXP service system according to the fourteenth embodiment uses a connection column definition table of the connection column definition class 1921 and a connection type definition table of the connection type definition class 1922 to connect to a plurality of tables (connection structure). And hierarchical structure). That is, there is an ER diagram as a method for indicating a table relation, but the dependency relationship of the table expressed in the ER diagram or the like corresponds to a connected column definition (JoinColumn) class 1921 and a connected type (JoinKind) class 1922. Specifically, as shown in FIG. 98, for example, in order processing, a table A 2201 (index: TranID), a table B 2202 (index: slip No.), and a table C 2203 (index: detail line No. and product code) have a hierarchical structure ( In the case of a parent-child relationship), an example of a table (concatenated column definition table) representing a parent-child relationship is shown in FIG. 98A as data items (columns), “management contents”, “subordinate table (TBL)”. ”,“ Identifier ”, and“ subordinate type ”. In addition, in the row (record) of the table A2201, which is the highest level (route) table, “table” is set as the item value of “management contents”, and “root” (there is no dependent TBL) as the item value of “subordinate TBL”. ”Is stored as“ NULL ”(because there is no subordinate TBL) as the item value of“ identifier ”, and“ 0 ”(meaning that there is no subordinate TBL) as the item value of“ subordinate type ”, respectively. . Further, in the row (record) of the table B2202 which is a middle level (child of the route table), “table” is set as the item value of “management contents”, and “A” (dependent TBL) is set as the item value of “subordinate TBL”. Means “Table A”), “TranID” (identifier of subordinate TBL) as the item value of “identifier”, and “1” (subordinate TBL is one) as the item value of “subordinate type” Each). Furthermore, in the row (record) of the table C2203 which is the lowest level (child of child table B), “table” as the item value of “management contents” and “B” (subordinate) as the item value of “subordinate TBL” TBL is table B), “slip No” (identifier of subordinate TBL) as the item value of “identifier”, and “1” (subordinate TBL is one subordinate item) as the item value of “subordinate type” Each means storing).

  On the other hand, for example, in the supplier unit price master, when the table a2211 (index: product ID), table b2212 (index: customer ID), and table c2213 (index: product ID and supplier ID) are in the connection structure, the connection structure is changed. An example of the table to be represented (concatenated column definition table) is, as shown in FIG. 98 (b), as data items (columns), “management contents”, “subordinate table (TBL)”, “identifier”, “subordinate type”. have. In addition, in the row (record) of the table a 2211 which is one of the concatenation source tables, “table” is set as the item value of “management contents” and “Root” (there is no subordinate TBL) as the item value of “subordinate TBL”. “Meaning” is stored as “identifier” item value “NULL” (because there is no subordinate TBL), and “subordinate type” item value “0” (meaning there is no subordinate TBL). Similarly, in the row (record) of the table b2212 which is the other of the connection source tables, “table” is set as the item value of “management contents”, and “Root” (there is no subordinate TBL) as the item value of “subordinate TBL”. ”Is stored as“ NULL ”(because there is no subordinate TBL) as the item value of“ identifier ”, and“ 0 ”(meaning that there is no subordinate TBL) as the item value of“ subordinate type ”, respectively. . On the other hand, two rows (records) of the table c2213, which is a concatenation destination table, are prepared corresponding to the two concatenation source tables. “A” (meaning that one subordinate TBL is table a) as the item value of “subordinate TBL”, “product ID” (identifier of one subordinate TBL) as the item value of “identifier” "2" (meaning that the number of subordinate TBLs is 2) is stored respectively, and in the lower row, "table" is stored as the item value of "management contents" “B” (meaning that the other subordinate TBL is table b) as the item value of “subordinate TBL”, “customer ID” (identifier of the other subordinate TBL) as the item value of “identifier” “2” as the item value of “Type” It means that the number of BL is two), respectively, and stores. The description of FIGS. 96 to 98 corresponds to the SXP feature 1.

FIG. 99 is an explanatory diagram showing an example of a concatenated column definition (JOIN_COLUMN) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 100 is an explanatory diagram showing an example of a connection type definition (JOIN_KIND) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
As shown in FIG. 99, the concatenated column definition table has “management content”, “identifier”, “corresponding content”, “identifier”, and “subordinate relationship (concatenation type definition)” as data items. For example, when defining the parent-child relationship of the table A2201, the table B2202, and the table C2203, the concatenated column definition table uses three rows as shown in the upper half, and the first row contains “management contents”. , “Identifier”, “corresponding content”, “identifier”, and “subordinate relationship (concatenation type definition)” as item values “A” (meaning that the management content is table A), “TranID”, “B” (meaning that the correspondence (child) is the table B), “TranID”, and “>” are stored. The “identifier” stores the identifier of the table A that is the parent table. In the second line, “B” (management content is a table) as item values of “management content”, “identifier”, “corresponding content”, “identifier”, and “subordinate relationship (concatenation type definition)”, respectively. B ”),“ TranID ”,“ C ”(meaning that the correspondence (child) is the table C),“ TranID ”,“> ”. The “identifier” stores the identifier of the table A that is the parent table. Further, in the third line, “B” (management content is a table) as item values of “management content”, “identifier”, “corresponding content”, “identifier”, and “subordinate relationship (linkage type definition)”, respectively. B ”means“ slip No ”,“ C ”(means that the correspondence (child) is the table C),“ slip No ”,“> ”. The “identifier” stores the identifier of the table B that is a child of the parent table A and a parent of the child table C. On the other hand, for example, when defining the connection structure of the table a2211, the table b2212, and the table c2213, the connection column definition table uses three lines as shown in the lower half of the table, and the first line contains “management contents”. , “Identifier”, “corresponding content”, “identifier”, “subordinate relationship (concatenation type definition)”, “a” (meaning that the management content is table a), “product ID”, respectively. , “C” (meaning that the correspondence content (link destination) is the table c), “product ID”, “>”. Note that the identifier of the table a which is one of the connection source tables is stored in the “identifier”. In the second line, “b” (management content is a table) as item values of “management content”, “identifier”, “corresponding content”, “identifier”, and “subordinate relationship (concatenation type definition)”, respectively. b)), “business partner ID”, “c” (meaning that the correspondence (consolidation destination) is the table c), “business partner ID”, “>”. In the “identifier”, the identifier of the table b which is the other source table is stored. Furthermore, in the third line, “a” (management content is a table) as item values of “management content”, “identifier”, “corresponding content”, “identifier”, and “subordinate relationship (linkage type definition)”, respectively. a), “product ID”, “b” (meaning that the corresponding content (consolidation source of the same hierarchy) is the table b), “customer ID”, “>”. The “identifier” stores the identifiers of the table a which is one concatenation source table and the table b which is the other concatenation source table.

FIG. 101 is an explanatory diagram showing an example of an event definition (EVENT) table in the data management system according to the fourteenth embodiment of the present invention. FIG. 102 is an explanatory diagram showing an example of a procedure definition (PROCEDURE) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 103 is an explanatory diagram showing an example of the item relation definition (COLUMN_CHAIN) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
As shown in FIG. 101, the event table has “event name (event_name)”, “procedure number (p_seq)”, “procedure name (procedure_name)”, and “condition code (condition_code)” as data items. Stores the corresponding item value for each event used. For example, when three procedures (p-1, p-2, p-3) are executed for the event a, item values are stored with the contents as shown in FIG. As shown in FIG. 102, the procedure definition table includes, as data items, “procedure name (procedure)”, “input data (input_data)”, “output data (output_data)”, “preprocessing (before_procedure)”, It has “post processing (after_procedure)” and “chain”, and stores corresponding item values for each procedure. For example, for the procedures p-1 to p-7, item values are stored with the contents as shown in FIG. Furthermore, as shown in FIG. 103, the item relation definition table includes “address (ID of item relation definition record)”, “target column (corresponding to the target column ID in the first to tenth embodiments)”, “main column”. (Corresponding to the trigger string ID in the first to tenth embodiments) ”,“ function ”,“ parameter 1 ”,“ parameter 2 ”, etc., and corresponding items for the item related definition data at each address Stores a value. That is, the item relation definition table used in the SXP service system of the fourteenth embodiment is similar to the process of the first to tenth embodiments described above for each address of the item relation definition data. Can exchange data between them. As a result, when each event occurs, only the item related definition data of the required address is analyzed, and data exchange between the main column ID and the target column ID is executed using only the necessary item related definition data. can do.

FIG. 104 is an explanatory diagram showing the concept of automatic generation of various XML data using the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
As shown in FIG. 104 (a), when the SXP service system according to the fourteenth embodiment is used, SXP (system exchange profile) that stores definition information of item definitions and item related definitions of profiles of each system and package software. 2301, input data such as a text file or unstructured data (unknown data) 2300 or CSV file is divided and analyzed using item definitions and item related definitions, etc. Style sheet definitions that generate tag names and attribute values to automatically generate XML data (data items and item values) 2310, automatically generate XSD 2311, which is a schema definition of XML data, and define the display mode of XML data XSL2312 can be automatically generated. For example, as shown in a table 2320 in FIG. 104 (b), the corresponding XML data can be analyzed and output using each class of SXP, and a row management table and item value management related to data can be analyzed. Using the table, the corresponding XML data can be analyzed and output. The description of FIG. 104 corresponds to the SXP feature 6.

FIG. 105 is an explanatory diagram showing a first example of data unified management by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
The SXP service system according to Embodiment 14 can be used for centralized data management in various modes. For example, as shown in FIG. 105, when the user selects a target system (selection support for data consistency check is a system), the SXP service system integrates data stored in each system. Displayed, and a warning is issued at a location suspected of data inconsistency. For example, when storing and managing data (product management data, etc.) of A package, B package, and C package, when a user inputs a specific product code (49XXXX001, etc.), the SXP service system The product management data of A package, B package, and C package corresponding to is extracted, and displayed in a list in a comparison table format. The product code used for the extraction is displayed on the left side of the uppermost column of the comparison table, and the display method is displayed on the right side of the uppermost column. Corresponding to the data items of each package, the data items of the standard profile are displayed on the left side. The item value of each package is displayed corresponding to the data item. Then, when there is a difference in the item value of the corresponding data item of each displayed package, the SXP system displays a warning on the column of the different data item by lighting in red or blinking. For example, in the example of FIG. 105, the unit price of the A package (19,800) and the upper price of the B package (20,000) need to be the same value, but those values differ due to an input error or the like. The system displays a warning in the standard retail unit price column. In addition to this, the user can easily check the data of each package by looking at the comparison table. The description of FIG. 105 corresponds to the SXP feature 5.

FIG. 106 is an explanatory diagram showing a second example of the unified data management by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
As an aspect of centralized data management of the second case, the SXP service system according to the fourteenth embodiment selects an item of each system to be analyzed by the user (selection support for analysis is a system). Data stored in each system is integrated and displayed, and analysis information is displayed on the screen using a graph display or the like. For example, when storing and managing data (product management data, etc.) of A package, B package, and C package, when a user inputs a specific product code (49XXXX001, etc.), the SXP service system The item values of desired data items are extracted from the product management data of the A package, B package, and C package corresponding to, and are displayed in a list in a comparison table format. The product code used for the extraction is displayed on the left side of the uppermost column of the comparison table, and the display method is displayed on the right side of the uppermost column. On the left side, display data items (order quantity, delivery quantity, return quantity, etc.) of each package are displayed, and the item value is displayed in a predetermined manner such as monthly corresponding to each display data item. . Thus, the user can easily confirm the analysis result for the data of each package by looking at the analysis table. The description of FIG. 106 corresponds to the SXP feature 5.

FIG. 107 is an explanatory diagram schematically showing an example of data conversion by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 108 is an explanatory diagram schematically showing an example of data conversion in consideration of data consistency by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
As shown in FIG. 107, in the case of normal data conversion by the SXP service system, the SXP service system 2350 obtains the system profile of the pre-conversion data and post-conversion data from the column management table (corresponding to the unique data profile of FIG. 85). Each determination is made, and the pre-conversion data is converted into post-conversion data using a conversion definition (corresponding to the conversion definition in FIG. 85) corresponding to the system profile in the item relation definition table. At this time, the SXP service system uses the column management table or the like to determine whether or not the conversion data has a predetermined data structure such as a hierarchical structure or a linked structure. The conversion data is stored separately according to the contents of the structure. For example, as shown in FIG. 107, slip data 2360 used in ordering work includes slip header data 2361 as header information, slip detail data 2362 (usually multiple lines) as body information, and slip as footer information. It has a data structure consisting of footer data 2363. Therefore, the SXP service system 2350 converts the slip data 2360 of a certain data format into slip data of another data format, and converts the slip header data 2361, the slip description data 2362, and the slip footer data 2363 of the slip data 2360, respectively. These are stored as separate slip header data 2371, slip detail data 2372 and slip footer data 2373. Note that the slip footer data may be collectively stored in the slip header data.

  On the other hand, as shown in FIG. 108, the SXP service system 2350 performs normal data conversion from pre-conversion data to post-conversion data as shown in FIG. Data item values of items can be extracted to process useful data separate from the conversion data. Specifically, as shown in FIG. 108, the SXP service system 2350 converts slip data 2360 (slip header data 2361, slip detail data 2362, slip footer data 2363) in the pre-conversion data format into a slip in the post-conversion data format. In addition to conversion into data (slip header data 2371, slip description data 2372, slip footer data 2373), the customer information part (ordering company code, ordering company name) of slip header data 2361 of slip data 2360 is separately provided. Extract and create supplier master data 2381 in the converted data format. Similarly, the SXP service system 2350 separately extracts the product information portion (product code, product name, unit price) of the slip specification data 2362 of each line of the slip data 2360 together with normal data conversion, and uses the converted data format. Product master data 2382 is created. In addition to this, for example, the SXP service system 2350 extracts the customer information from the slip header data 2361 of the slip data 2360 and also extracts the sales information (amount information) from the slip footer data 2363 and aggregates it every predetermined period. By doing so, it is also possible to create a transaction volume table showing the transaction volume of a predetermined customer every week, every month, or every year. As described above, the SXP service system 2350 can obtain normal post-conversion data (import data) from pre-conversion data (export data), and can also obtain other types of data and descend a desired table. it can. As a result, on the data import side, in addition to the slip data, which is normal conversion data, other import information such as customer master data 2381 and product master data 2382 can be output.

  Further, according to the function of the SXP service system 2350, it is easy to exchange data while maintaining data consistency. That is, as described above, the SXP service system 2350 reads the data to be converted for each record and stores the row ID information (data for specifying each record) of each record in the row management table. Each record of the read data is divided into data items (fields) and stored in the value management table according to the item definition (column ID, etc.) of the column management table. At this time, data conversion via the standard profile is executed using the item relation definition table. For the converted data, the data item value is acquired from the value management table with reference to the row ID of the row management table and the column ID of the column management table as necessary, and the desired format (view) Can be output (displayed, printed, etc.). Thus, according to the SXP service system 2359, as described above, basically, with respect to data of an arbitrary data format, the corresponding data profile (system profile) of the column management table and the corresponding conversion of the item relation definition table Using the definition, the data can be converted into data of another arbitrary data format, and the data can be converted with a very simple configuration. In addition to this, according to the SXP service system, two very unique and simple tables, a row management table and a value management table, are used to convert the data after data conversion (information for record identification and value related information). Can be stored and saved. That is, according to the SXP service system, data conversion and storage of arbitrary data is basically performed using a very simple table configuration including a column management table, an item relation definition table, a row management table, and a value management table. Acquisition, processing, output, etc. can be realized.

  Here, the SXP service system 2350 stores the data item values of all the data (records) converted as described above in the value management table (divided for each data item value). Therefore, by using the data stored in the value management table, it is possible to determine whether newly read data is consistent with the previous read data (stored data), while maintaining data consistency. Data conversion and data import can be realized. For example, when the product name of a specific product ID (for example, “001”) of the specific slip data in the stored data is “PariPari Senbei” and the unit price is “100 yen”, the newly read slip data When the product name of the product ID (001) is “Bariba Risenbei” or the unit price is “110 yen” (if different from the stored data), the SXP service system 2350 Such inconsistency can be recognized by the consistency check, and an error display, warning display, etc. can be given to the user. Then, by performing data conversion by checking or correcting inconsistent data one by one, it is possible to store data with completely ensured consistency. As a result, the SXP service system 2350 always provides data consistency for users who are difficult to invest sufficient human resources and costs in the system, such as small and medium-sized enterprises, or who are unfamiliar with the handling of the system. Data conversion and data storage with high reliability are possible, and the system becomes very highly utilized. Further, as described above, the SXP service system 2350 converts the original data (for example, slip data) and converts other arbitrary data (master data and transaction data) such as customer master data and product master data. ) Because it can be created, even for small and medium-sized enterprises where it is difficult to prepare a sufficient system environment, all master data and transaction data are automatically generated and stored in the corresponding table. Therefore, the system becomes very suitable as a so-called SAAS.

  In other words, the SXP service system 2350 stores and manages all master data and transaction data of any company or any system in two simple tables, a row management table and a value management table having the same format. If necessary, a column management table and an item relation definition table can be used to output data in an arbitrary data format to provide an arbitrary type of view.

  As described above, the SXP service system described with reference to FIG. 108 converts the conversion source target data (slip data 2360) to the conversion target data (slip data 2371 to 2373). Some data item values (ordering company code of the slip header data 2361, etc.) and the slip details data 2362 of the master data (customer master data 2381, product master data 2382, etc.) from the target data (slip data 2360) Product code, etc.) are extracted separately, and the extracted data item values are converted according to a predetermined data format (customer master data or product master data format) to obtain master data (customer master data 2381, product master). Create and store data 2382 etc.) At the time of data conversion from the conversion target data to the conversion target data, the stored master data (customer master data 2381, product master data 2382, etc.) and master data newly created at the subsequent data conversion Compare with (newly read supplier master data, product master data, etc.), and determine consistency between them.

FIG. 109 is an explanatory diagram showing the concept of format sharing such as barcodes and electronic tags used in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 110 is a diagram illustrating the concept of an application utilizing a data identification format (shared format) such as a barcode or an electronic tag by the system exchange profile (SXP) service system as a data management system according to the fourteenth embodiment of the present invention. FIG.
In the distribution of commercial transactions, usage scenes of bar codes and electronic tags attached to products or tags have been increasingly proposed. However, the barcode format varies depending on whether the ordering company is designated or the carrier is unique. On the other hand, by sharing the header portion of the barcode format (for example, as shown by the belt-like code in FIG. 109), it is possible to determine which format of which company the data to which the barcode is attached is. Can do. In this way, detailed information after that can be determined using the SXP data conversion and exchange technique of the present embodiment. Note that detailed information after the header (information on the body part) is information for each industry and product, so it is difficult to share the format of all data. Therefore, as shown in FIG. 109, the SXP service system according to the fourteenth embodiment includes the header portion of the data format of the barcode 2401 attached to the product / packaging 2400 and the electronic tag 2411 attached to the product / packaging 2410. Only the common format is shared (shared). For example, as a common format for data headers (file headers) such as barcodes and electronic tags, the company code is 6 digits + table identifier 4 digits + version ID 2 digits + supplier code 6 digits + security identifier 16 digits. Then, as shown in FIG. 110, an application that effectively uses this common format as the data identification format can be implemented. For example, the barcode application 2500 determines the URL of the web page that is the storage area for the packing details information from the content of the header information of the read barcode, and after downloading the packing details information from the web page of the website And display the contents of the packing list on the screen. On the other hand, the electronic tag application 2510 refers to the SXP of the supplier in advance and downloads and stores the packing details information from the website (SXP service provider) to its local PC. Then, the SXP to be used is determined from the contents of the header of the read electronic tag, and the packing details as detailed information of the electronic tag are displayed on the screen by the application on the local PC. In any of the applications 2500 and 2510, when the content displayed on the screen is checked or edited, the SXP is referred to and the result is output to a designated folder on the local PC in a format designated in advance by the user. If necessary, the work log file and receipt can be output from the printer to the local printer, or the received data can be returned immediately to the delivery company. The description of FIGS. 109 and 110 corresponds to the SXP feature 10 described above.

FIG. 111 is an explanatory view showing the concept of automatic conversion processing by data upload in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention.
In the automatic conversion process by data upload by the SXP service system according to the fourteenth embodiment, as shown in FIG. 111, first, the data transmission company 2600 transmits data before conversion on the Internet in which a data conversion method is designated or predetermined. When the authentication information 2650 such as the terminal ID, login ID, and password is input to the destination folder 2620 to log in, and when the data transmission destination is designated or predetermined and the pre-conversion data 2601 is transmitted, the SXP engine 2630 displays the pre-conversion data. 2601 is converted and exchanged (including encryption / decryption), and the resulting output data (converted data) is output to the converted data receiving folder 2640 defined on the Internet, generated, and converted. The pre-conversion data 2601 is deleted from the previous data transmission destination folder 2620. To. Thus, the SXP service system according to the fourteenth embodiment can be used as a data transmission / reception infrastructure defined between companies with transactions. That is, when the data transmission company 2600 is the orderer and the data receiving company 2610 is the contractor, when the data transmission company 2600 transmits the order data to the pre-conversion data transmission destination 2620, the SXP engine 2630 converts and converts the order data. The data is transmitted / stored in the subsequent data reception destination folder 2640, and the order data of the pre-conversion data transmission destination 2620 is deleted. As a result, the data receiving company 2610 as the contractor inputs the authentication information 2650 such as the terminal ID, login ID, and password into the converted data receiving folder 2640 and logs in, and converts the converted data (ordered data after conversion). ) 2611 can be acquired and order processing can be performed. Further, the data transmission company 2600 that is the orderer also logs in by inputting authentication information 2650 such as a terminal ID, a login ID, and a password into the converted data receiving folder 2640 and converts the converted data (ordered data after conversion). 2611 can be acquired. For convenience, the authentication information 2650 of the data transmitting company and the authentication information 2650 of the data receiving company are indicated by the same number 2650, but usually unique authentication information is assigned to each user.

FIG. 112 is an explanatory view showing the concept of automatic conversion processing by reading shared header information in a system exchange profile (SXP) service system as a data management system according to Embodiment 14 of the present invention.
The automatic conversion process by reading the shared header information in the SXP service system 2350 as the data management system according to the fourteenth embodiment is based on the same concept as the shared format described with reference to FIGS. Header information is shared (shared), and automatic conversion processing is performed based on the shared data. Specifically, as shown in FIG. 112, when the barcode 2401 attached to the product / packaging 2400 is first read, the SXP service system 2350 reads out the header information as shared information from the read barcode information. Based on the header information, the data of the main part of the read barcode information (slip data, packing data, etc.) is sent from which company (source) to which company (destination). It is determined whether the data (transmission source unique data before conversion), and based on this determination, the storage location of the data of the main body linked to the barcode 2401 and the system profile of the data of the main body are determined. To do. At this time, the SXP service system 2350 uses the shared system for the shared format in the header information display area 2751 of the monitor screen 2750 in a format in which the header information of the read barcode 2401 can be confirmed (barcode information Rather than display as it is, it is displayed after converting the character string into the type of read data, the source, the destination, etc. In this way, the user can confirm the header information (shared information) of the read barcode information and use it for the convenience of the subsequent work. Next, based on the determination, the SXP service system 2350 stores the data of the main body in the predetermined storage destination 2710 as the transmission source unique pre-processing data 2711 and stores the stored transmission original unique data 2711. Conversion to the SXP standard profile 1250 is performed according to the conversion definition 2721 (conversion definition for the transmission source unique pre-processing data 2711 in the item relation definition table) which is the selected unique system profile. At this time, the SXP service system 2350 uses the shared system for the shared format in a format in which the data of the main part of the converted standard data format can be confirmed in the main part data display area 2752 of the monitor screen 22750 ( Display the contents of the read data (converted into a character string) instead of the barcode information. In this way, the user can confirm the contents of the main body data of the read bar code information and use it for the convenience of the subsequent work. The header information may be displayed simultaneously with the display of the main body data, not at the timing immediately after reading the header information. Further, based on the determination, the SXP system converts the converted standard format data (transmission source data) into the conversion definition 2722 (conversion for the reply destination post-processing data 2712 in the item related definition table) which is the selected unique system profile. In accordance with the definition), the data is converted into post-return destination data 2712 and stored in the storage destination 2710. The same processing can be performed when the electronic tag 2411 attached to the product / packaging 2410 is used.

  In addition to the above processing, the automatic conversion processing using the shared header information associates an arbitrary application with the shared header information (transfers it simultaneously if necessary), and reads the shared header information. It is also possible to perform processing that automatically starts the application by input and automatically executes an operation according to the function of the application. In this way, users of SMEs who do not have a common system or software can automatically execute processing based on shared header information using the same application (which they do not own). The same work can be easily performed. For example, the automatic conversion process using the shared header information may be a process for executing a function of executing a predetermined inspection process by starting an inspection application simultaneously with the input of the shared header information. In this way, with this SXP service system, even users who do not have inspection software can automatically send inspection results by the same process to each other and convert the data, dramatically improving work efficiency. Can be improved.

  As described above, the SXP service system described with reference to FIG. 112 has the transmission source information that uniquely indicates the transmission source of the target data for each of the target data, and the system corresponding to the target data of the transmission source. Source system profile specifying information uniquely indicating a profile, source item related definition specifying information uniquely indicating the item related definition information corresponding to the target data of the source, and a destination of the target data uniquely Destination information, destination system profile specifying information that uniquely indicates the system profile corresponding to the target data of the destination, and a destination item that uniquely indicates the item related definition information corresponding to the target data of the destination Header information consisting of shared information in a common format having related definition specific information (header information of barcode 2401) To add. And this SXP service system performs the following processes at the time of transmission of the conversion target data. That is, the SXP service system first determines the storage destination 2710 of the target data 2711 of the conversion source based on the transmission source information of the header information of the target data 2711 of the conversion source, and selects based on the determination The target data 2711 of the conversion source is stored in the storage destination 2710, and then, based on the source system profile specifying information and the source item related definition specifying information of the header information of the target data 2711 of the conversion source, The system profile corresponding to the conversion source target data 2711 (not shown in FIG. 112 but corresponding to the unique data profile 1252 in FIG. 85, for example) and item related definition information (conversion definition 2721) are determined, and the determination is made. Using the system profile and the item definition information selected based on The target data 2711 of the conversion source stored in the destination 2710 is converted into standard data according to the standard data format of the SXP standard profile 1250, and then the transmission destination system of the header information of the target data 2711 of the conversion source Based on the profile specifying information and the destination item related definition specifying information, the system profile and item related definition information corresponding to the conversion target data 2712 is determined, and the system profile selected based on the determination (FIG. 112). Although not shown in the figure, for example, the standard data is set in the data format of the target data 2712 of the transmission destination by using the item definition information (conversion definition 2722) and the item definition information (conversion definition 2722). Converted to the destination data 2712 Next, the storage location 2710 of the transmission destination data 2712 is determined based on the transmission destination information of the header information of the target data 2711 of the conversion source, and the transmission destination data is transferred to the storage location 2710 selected based on the determination. 2712 is stored.

FIG. 113 is an explanatory diagram showing the concept of automatic conversion processing by reading shared header information in a system exchange profile (SXP) service system as a data management system according to Embodiment 14 of the present invention.
As described above, the SXP service system can handle data exchange between all systems, and can be a so-called message-driven system that is activated by handling the exchanged data as a message and receiving the message. . In this case, for example, as shown in FIG. 113, the exchanged data includes header information including a message number (Message_No), a transmission source company (Send_Customer_ID), a transmission destination company (Receive_Customer_ID), a message type (Message_ID), and data. It consists of content information as the main phone. Among these, the message type can be composed of a system XML tag name (System_XML_Tag) and a table XML tag name (Table_XML_Tag). The system XML tag name uniquely indicates the type of system, and the table XML tag name uniquely indicates a table in the system. As described above, the SXP service system 2350 can manage any message by uniquely defining the message type with the two items of the system XML tag name and the table XML tag name.

FIG. 1 is a block diagram schematically showing a configuration of a sales management system as a data management system according to Embodiment 1 of the present invention. FIG. 2 is an explanatory diagram schematically showing the data structure of the data management system according to the first embodiment of the present invention. FIG. 3 is an explanatory diagram schematically showing a data structure when the data management system according to Embodiment 1 of the present invention is embodied in a sales management system. FIG. 4 is an explanatory diagram showing a product master table as an example of data definition (physical table structure) in a conventional data management system. FIG. 5 is an explanatory diagram showing a customer master table as an example of data definition (physical table structure) in a conventional data management system. FIG. 6 is an explanatory diagram showing a customer unit price master table as an example of data definition (physical table structure) in a conventional data management system. FIG. 7 is an explanatory diagram showing an inventory master table as an example of data definition (physical table structure) in a conventional data management system. FIG. 8 is an explanatory diagram showing a sales master table as an example of data definition (physical table structure) in a conventional data management system. FIG. 9 is an explanatory diagram showing a column management table in a case where the conventional data management system of FIGS. 4 to 8 is replaced by the data management system according to the first embodiment of the present invention. FIG. 10 is an explanatory diagram showing a row management table in a case where the conventional data management system of FIGS. 4 to 8 is replaced by the data management system according to the first embodiment of the present invention. FIG. 11 is an explanatory diagram showing a first specific example of a value management table in a case where the conventional data management system of FIGS. 4 to 8 is replaced by the data management system according to the first embodiment of the present invention. FIG. 12 is an explanatory diagram showing a second specific example of the value management table in the case where the conventional data management system of FIGS. 4 to 8 is replaced by the data management system according to the first embodiment of the present invention. FIG. 13 is a block diagram schematically showing the configuration of an ordering management system as a data management system according to Embodiment 2 of the present invention. FIG. 14 is an explanatory diagram schematically showing a data structure when the data management system according to the second embodiment of the present invention is embodied in an order placement management system. FIG. 15 is an explanatory diagram showing a data structure of order data exchanged in the data management system according to the second embodiment of the present invention. FIG. 16 is an explanatory diagram showing an outline of a column management table used in the data management system according to the second embodiment of the present invention. FIG. 17 is an explanatory diagram showing a correspondence relationship between the record of the order data and the attribute of each data item of the order data defined in the column management table by the data management system according to the second embodiment of the present invention. FIG. 18 shows the order data received from the outside in the data management system according to the second embodiment of the present invention, the order data is stored in the ordering company designation data storage area, and the slip record and the slip detail record are respectively stored in the slip. It is a block diagram showing a data flow in a slip basic record / slip item value storage procedure stored in a slip detail storage area. FIG. 19 is an explanatory diagram schematically showing a procedure for exchanging data between an ordering company data profile and an ordering company data profile via a standard data profile by the data management system according to the second embodiment of the present invention. FIG. 20 shows the standard data corresponding to the item value of the ordering company data from the predetermined column ID of the ordering company data profile representing the predetermined item value of the ordering company data by the data management system according to the second embodiment of the present invention. The procedure for acquiring the predetermined column ID of the order data profile representing the item value of the order receiving company data corresponding to the item value of the standard data via the predetermined column ID of the standard data profile representing the item value of It is explanatory drawing which shows FIG. 21 shows an outline of an item value management table used for processing when the meaning and method of use of item values differ between companies when data is exchanged by the data management system according to the second embodiment of the present invention. It is explanatory drawing. FIG. 22 incorporates a new ordering company data profile and link information between the ordering company profile and the standard data profile into the data management system according to the second embodiment of the present invention, and stores data based on the new ordering company data profile. It is a block diagram which shows the data flow in the profile taking-in / display / output procedure in the case of displaying and outputting. FIG. 23 is a block diagram showing a data flow in a data output procedure for outputting various data by the data management system according to the second embodiment of the present invention. FIG. 24 is a block diagram schematically showing the configuration of the data management system according to the third embodiment of the present invention together with the profile management system. FIG. 25 is a data flow diagram showing data to be exchanged in the electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention in accordance with the transaction process. FIG. 26 is a table showing a list and configuration of data to be exchanged in the electronic commerce data exchange system as the data management system according to the fourth embodiment of the present invention. FIG. 27 is a data structure diagram showing a data structure of standard data used in an electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention. FIG. 28 is a table relation diagram showing a data structure of an electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention. FIG. 29 is a table showing a table list used in an electronic commerce data exchange system as a data management system according to Embodiment 4 of the present invention. FIG. 30 is an explanatory view schematically showing matching processing when a difference occurs between ordering data and shipping data by the electronic commerce data exchange system as a data management system according to the fourth embodiment of the present invention. is there. FIG. 31 is an explanatory diagram showing the overall configuration of a network system that implements electronic commerce data exchange by applying the data management system according to the fifth embodiment of the present invention. FIG. 32 is a block diagram showing a relationship between a general table structure and three physical tables of the data management system according to the fifth embodiment of the present invention. FIG. 33 is an explanatory diagram showing the concept of the three physical tables of the data management system according to the fifth embodiment of the present invention. FIG. 34 is a block diagram for explaining the processing of the record hierarchical structure in the three physical tables of the data management system according to the fifth embodiment of the present invention. FIG. 35 is a flowchart showing a business flow when the data management system according to Embodiment 5 of the present invention is applied to a distribution support system for a distribution company. FIG. 36 is an explanatory diagram showing a company management (CUSTOMER) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention. FIG. 37 is an explanatory diagram showing a data exchange management (EXCHANGE) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 38 is an explanatory diagram showing a data type (DATA_KIND) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention. FIG. 39 is an explanatory diagram showing a table management (TABLE) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 40 is an explanatory diagram showing a standard data profile portion of a column management (COLUMN) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 41 is an explanatory diagram showing an ordering company data profile portion of the column management (COLUMN) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention. FIG. 42 is an explanatory diagram showing an order enterprise data profile portion of a column management (COLUMN) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. 434 is an explanatory diagram showing an item value management (COLUMN_VALUE) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention. FIG. 44 is an explanatory diagram showing an item relation definition (COLUMN_CHAIN) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 45 is an explanatory diagram showing a function management (FUNCTION) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 46 is an explanatory diagram showing a target management (SYSTEM_OBJECT) table used in the electronic commerce data exchange system as the data management system according to the fifth embodiment of the present invention. FIG. 47 is an explanatory diagram showing a row management (ROW) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 48 is an explanatory diagram showing a value management (CELL) table used in the electronic commerce data exchange system as a data management system according to the fifth embodiment of the present invention. FIG. 49 is a block diagram for explaining the concept when the data management system according to Embodiment 6 of the present invention is applied to a system development support CASE tool. FIG. 50 is a block diagram for explaining the concept of bidirectional data conversion between tables in the data management system according to the sixth embodiment of the present invention. FIG. 51 shows the concept of one-way (one-way) data conversion between the table and the form of the data management system according to the sixth embodiment of the present invention. FIG. 51 (a) is a block for explaining the concept of data conversion. FIG. 4B is a block diagram showing a specific example 1, and FIG. FIG. 52 is a block diagram for explaining the concept of processing when the display method of the amount of money on the delivery slip is different in the data management system according to the sixth embodiment of the present invention. FIG. 53 shows the concept of bidirectional data conversion between the table and the display screen of the data management system according to the sixth embodiment of the present invention, (a) is a block diagram for explaining the concept of data conversion, b) is a block diagram showing a specific example 1, and (c) is a partial block diagram showing a specific example 2. FIG. 54 is an explanatory diagram schematically showing a column management table used in the data management system according to the sixth embodiment of the present invention. FIG. 55 is an explanatory diagram schematically showing a form profile item management (FORM_COLUMN) table used in the data management system according to the sixth embodiment of the present invention. FIG. 56 is an explanatory diagram schematically showing a form (FORM) table used in the data management system according to the sixth embodiment of the present invention. FIG. 57 is an explanatory diagram schematically showing a setting example of a column management table used in the data management system according to the sixth embodiment of the present invention. FIG. 58 is an explanatory diagram schematically showing a setting example of a screen display profile item management (FORM_COLUMN) table used in the data management system according to the sixth embodiment of the present invention. FIG. 59 is an explanatory diagram schematically showing a setting example of a screen display (FORM) table used in the data management system according to the sixth embodiment of the present invention. FIG. 60 is a block diagram illustrating a setting example of a screen display profile item management (FORM_COLUMN) table used in the data management system according to the sixth embodiment of the present invention. FIG. 61 is a flowchart showing the ordering company data reading / storing process of the data management system according to the second to sixth embodiments of the present invention. FIG. 62 is a flowchart showing the slip list display process of the data management system according to the second to sixth embodiments of the present invention. FIG. 63 is a flowchart showing slip detail display processing of the data management system according to Embodiments 2 to 6 of the present invention. FIG. 64 is a flowchart showing the ordering company original data acquisition process in the slip detail display process of the data management system according to the second to sixth embodiments of the present invention. FIG. 65 is a flowchart showing the ordering company slip data acquisition process in the slip detail display process of the data management system according to the second to sixth embodiments of the present invention. FIG. 66 is a flowchart showing system standard data acquisition processing in slip details display processing of the data management system according to Embodiments 2 to 6 of the present invention. FIG. 67 is a flowchart showing the order receiving company designation data acquisition process in the slip detail display process of the data management system according to the second to sixth embodiments of the present invention. FIG. 68 is a flowchart showing data output processing of the data management system according to Embodiments 2 to 6 of the present invention. FIG. 69 is a flowchart showing item value conversion processing of the data management system according to Embodiments 2 to 6 of the present invention. FIG. 70 is a block diagram illustrating features of data conversion processing and display processing of the data management system according to Embodiments 1 to 6 of the present invention. FIG. 71 is a block diagram for explaining display processing of data conversion processing of a conventional data management system. FIG. 72 is an explanatory diagram showing a column management table of the data management system according to the seventh embodiment of the present invention. FIG. 73 is an explanatory diagram showing a function management table of the data management system according to the eighth embodiment of the present invention. FIG. 74 is an explanatory diagram showing a function table of the data management system according to the ninth embodiment of the present invention. FIG. 75 is an explanatory diagram showing an index management table of the data management system according to the tenth embodiment of the present invention. FIG. 76 is an explanatory diagram showing a row relation management table of the data management system according to the tenth embodiment of the present invention. FIG. 77 is a block diagram schematically showing the configuration of a sales management system as a conventional data management system. FIG. 78 is a data flow diagram schematically showing an aspect of data conversion between a plurality of conventional enterprise systems. FIG. 79 is a data flow diagram schematically showing an aspect of data mapping in data conversion between a plurality of conventional enterprise systems. FIG. 80 is a data flow diagram schematically showing an aspect of data stored in a conventional application system (package software). FIG. 81 is a data flow diagram schematically showing an aspect of data conversion between a plurality of conventional application systems (package software). FIG. 82 is a data flow diagram schematically showing a manual data processing operation at the time of export / import in data conversion between a plurality of conventional application systems (package software). FIG. 83 shows automatic data processing at the time of export / import in data conversion between a plurality of application systems (package software) by the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention. It is a data flow figure showing roughly. FIG. 84 shows the required system number (necessary mapping number) in the case of data exchange using a standard profile by the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention. It is a data flow figure shown in comparison with the number of required systems (the number of required mapping) in the case of data exchange by. FIG. 85 shows a data conversion mechanism between a plurality of enterprise systems by a system exchange profile (SXP) service system as a data management system according to the eleventh embodiment of the present invention. It is explanatory drawing demonstrated in comparison with. FIG. 86 exemplifies data structures and file configurations (table related) of various industries, various systems, and various package software used in the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention. It is a data structure figure. FIG. 87 is a table showing a list of databases used in the system exchange profile (SXP) service system as the data management system according to the eleventh embodiment of the present invention. FIG. 88 is an overview of data exchange processing between different application systems (package software) using a standard profile (general-purpose product profile) by a system exchange profile (SXP) service system as a data management system according to the eleventh embodiment of the present invention. FIG. FIG. 89 is a data flow diagram showing an overview of a system profile distribution service system by a system exchange profile (SXP) service system as a data management system according to the twelfth embodiment of the present invention. FIG. 90 shows creation and distribution processing of an industry system profile by a system exchange profile (SXP) service system as a data management system according to the thirteenth embodiment of the present invention, and creation of a package system profile by a package development vendor of the industry. It is a data flow figure which shows the outline | summary of a delivery process and the related definition process of the said industry system profile and the system profile of a package. FIG. 91 is a data flow diagram schematically showing the relationship between the business flow of a conventional small business and electronic data exchange (EDI). FIG. 92 is a data flow diagram schematically showing an aspect of data management by the conventional package software for small and medium enterprises. FIG. 93 is a data flow diagram schematically showing the relationship between a conventional electronic data exchange (EDI) and an existing system, taking as an example an order processing job. FIG. 94 is a data flow diagram showing an outline of the usage form of data exchange processing by the conventional package software for small and medium enterprises. FIG. 95 is an explanatory diagram showing an outline of the overall configuration of a system exchange profile (SXP) service system as a data management system according to the fourteenth embodiment of the present invention. FIG. 96 is a schematic configuration diagram of classes for processing a system profile of a system exchange profile (SXP) service system as a data management system according to the fourteenth embodiment of the present invention. FIG. 97 is a data flow diagram showing an outline of data conversion processing by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 98 is an explanatory diagram showing an outline of the connection / correspondence relationship between tables by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 99 is an explanatory diagram showing an example of a concatenated column definition (JOIN_COLUMN) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 100 is an explanatory diagram showing an example of a connection type definition (JOIN_KIND) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 101 is an explanatory diagram showing an example of an event definition (EVENT) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 102 is an explanatory diagram showing an example of a procedure definition (PROCEDURE) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 103 is an explanatory diagram showing an example of the item relation definition (COLUMN_CHAIN) table in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 104 is an explanatory diagram showing the concept of automatic generation of various XML data using the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 105 is an explanatory diagram showing a first example of data unified management by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 106 is an explanatory diagram showing a second example of the unified data management by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 107 is an explanatory diagram schematically showing an example of data conversion by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 108 is an explanatory diagram schematically showing an example of data conversion in consideration of data consistency by the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 109 is an explanatory diagram showing the concept of format sharing such as barcodes and electronic tags used in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 110 is a diagram illustrating the concept of an application utilizing a data identification format (shared format) such as a barcode or an electronic tag by the system exchange profile (SXP) service system as a data management system according to the fourteenth embodiment of the present invention. FIG. FIG. 111 is an explanatory diagram showing a concept of automatic conversion processing by data upload in the system exchange profile (SXP) service system as the data management system according to the fourteenth embodiment of the present invention. FIG. 112 is an explanatory view showing the concept of automatic conversion processing by reading shared header information in a system exchange profile (SXP) service system as a data management system according to Embodiment 14 of the present invention. FIG. 113 is an explanatory diagram showing the concept of automatic conversion processing by reading shared header information in a system exchange profile (SXP) service system as a data management system according to Embodiment 14 of the present invention.

Explanation of symbols

1310: Item definition information for system 1320: Item related definition information 1330: Item definition information for standard profile

Claims (8)

Item definition information for system profiles that define different system data formats,
Item definition information for standard profiles that covers item definition information for all systems to be managed,
Storing item relation definition information for defining a correspondence relationship between the item definition information for the system profile and the item definition information for the standard profile;
Using the item definition information for the system profile, the item definition information for the standard profile, and the item related definition information, export data items according to the profile of one of the two different systems, A data management system characterized by automatically converting data items of import data according to the profile of the other system. A column management file that pre-defines and statically stores at least a column ID that uniquely indicates each data item of the system and a column ID that uniquely indicates each data item of the standard profile; Storing the item definition information for the system profile and the item definition information for the standard profile,
An item relation definition file that pre-defines and stores a correspondence relationship between a column ID that uniquely indicates each data item of the system and a column ID that uniquely indicates each data item of the standard profile, The data management system according to claim 1, wherein the item related definition information is stored in a definition file.   The item definition information for the system profile and the item definition information for the system profile, and the item related definition information for the system profile that defines a correspondence relationship between the item definition information for the standard profile, as a pair, The system which is stored on the network, downloads the item definition information for the system profile of any at least two systems and the item-related definition information for the system profile, and downloads them in response to a user request Using a pair of the item definition information for profile and the item related definition information for the system profile and the item definition information for the standard profile, the data format of one of the at least two systems According to the export data A data item, the data management system of claim 1, wherein the automatically into data items of import data in accordance with the data format of the other system. A data management system that performs data conversion between target data having different data formats,
A system profile that is created for each target data to be data converted, stores a column ID that uniquely indicates a data item that constitutes a record of each target data, and defines a data format of each target data;
A data item that covers all data items of all the target data, together with a column ID that uniquely indicates the data item, and a standard profile that defines a standard data format of the target data;
Item-related definition information that defines the correspondence and conversion process between the data items of each system profile and the data items of the system profile in the standard profile;
A row management file that stores a row ID uniquely indicating the read record in correspondence with the read record when the record of the target data is read;
When reading the record of the target data, the field value of the data item of the read record is changed to the row ID that uniquely indicates the read record and the data item of the data item value in the read record stored in the column management file. A value management file that is uniquely identified and stored by the corresponding column ID,
A data format of target data as a conversion source is determined based on the system profile corresponding to the target data, and the target data is determined based on the item related definition information corresponding to the target data. To standard data according to
The data format of the target data to be converted is determined based on the system profile corresponding to the target data, and converted from the target data to be converted by the item related definition information corresponding to the target data A data management system, wherein the standard data is converted into data according to a data format of target data to be converted.   Further, at the time of data conversion from the conversion target data to the conversion target data, some data item values are separately extracted from the conversion target data, and the extracted data item values are set to predetermined data Converted according to the format to create and store additional data, and at the time of data conversion from the target data of the conversion source to the target data of the conversion destination, the stored additional data and new data at the time of subsequent data conversion 5. The data management system according to claim 4, wherein the created additional data is compared to determine consistency between them.   Furthermore, when data is converted from the target data of the conversion source to the target data of the conversion destination, some data item values constituting master data are separately extracted from the target data of the conversion source, and the extracted data items Master data is created and stored by converting the value according to a predetermined data format, and at the time of data conversion from the target data of the conversion source to the target data of the conversion destination, the stored master data and the subsequent 5. The data management system according to claim 4, wherein the master data newly created at the time of data conversion is compared to determine consistency between them.   For each of the target data, system profile specifying information that uniquely indicates the system profile corresponding to the target data, and item related definition specifying information that uniquely indicates the item related definition information corresponding to the target data. Adding at least shared information of a common format having, and at the time of reading the target data of the conversion source, based on the shared information, determining the system profile and the item definition information corresponding to the target data of the conversion source, 5. The data management system according to claim 4, wherein the target data of the conversion source is converted into standard data according to a standard data format of the standard profile using the corresponding system profile and the item definition information. . For each of the target data, transmission source information that uniquely indicates the transmission source of the target data, transmission source system profile specifying information that uniquely indicates the system profile corresponding to the target data of the transmission source, and the transmission Source item related definition specifying information that uniquely indicates the item related definition information corresponding to the original target data, transmission destination information that uniquely indicates a destination of the target data, and the data corresponding to the target data of the destination A header composed of shared information in a common format having transmission destination system profile specifying information uniquely indicating a system profile and transmission destination item related definition specifying information uniquely indicating the item related definition information corresponding to the target data of the transmission destination Add information,
When sending the target data of the conversion source,
Based on the transmission source information of the header information of the conversion source target data, the storage source of the conversion source target data is determined, and the conversion source target data is stored in the storage destination selected based on the determination. ,
Based on the transmission source system profile identification information and transmission source item related definition identification information in the header information of the conversion source target data, determine the system profile and item related definition information corresponding to the conversion source target data, Using the system profile and the item definition information selected based on the determination, the target data of the conversion source stored in the storage destination is converted into standard data according to the standard data format of the standard profile,
Based on the transmission destination system profile identification information and transmission destination item related definition identification information of the header information of the target data of the conversion source, determine the system profile and item related definition information corresponding to the target data of the conversion destination, Using the system profile selected based on the determination and the item definition information, the standard data is converted into destination data according to the data format of the target data of the destination,
A storage location of the transmission destination data is determined based on transmission destination information of the header information of the conversion target data, and the transmission destination data is stored in a storage destination selected based on the determination. The data management system according to claim 4.

Images