JP2009223512A - Information processing system and its control method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To operate Unix files used by legacy applications in a new system without alternating the legacy application and decrease the manhours for creating an application to improve the productivity by integrating, as a virtual table or a virtual column, the Unix files into a relational database of the new system. <P>SOLUTION: Based on definition information, an information processing system assigns real data of a column in another table to a virtual column, opens a Unix file without alternating the file, assigns an entire or part of the file as an entity of an entire or part of a virtual table, a virtual column or cells of the virtual column, and also accesses the data in response to a relevant reading/writing request, and then, takes in the data so as to include it as a table or the part of the table into the database. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to information processing technology that uses a relational database and a Unix (registered trademark) file in an integrated manner.

  When a computer system that has been used for many years is updated to a new system due to its aging, it is necessary to migrate the database used in the old system to the database of the new system. At that time, the data accumulated in the database of the old system is extracted (Extract), the relational database is transformed into a form that can be easily used by software such as data warehouse (Transform), and written to the database (Load) A series of processes is executed, and this series of processes is called an ETL process (for example, refer to Non-Patent Document 1).

  A dedicated program is required to execute such ETL processing, but the program absorbs differences in data formats and interfaces in order to maintain data compatibility between the old system and the new system. It has been necessary to do so, and the elements related to the system development occupy a large number of man-hours for system development, so much effort has been required for program development (for example, see Non-Patent Documents 2 and 4).

  Therefore, recently, ETL tools that perform ETL processing mechanically have been widely used. The ETL tool is equipped with a graphic user interface (GUI) to display the flow from database to database in an easy-to-understand manner, convert data formats and column types, delete unnecessary data, and standardize the format. (For example, refer nonpatent literature 3).

  Most of such ETL tools are adapted to commercial databases, but ETL tools for open source databases have also appeared (for example, see Non-Patent Document 4).

  Even when an old system that uses a Unix file as system data is migrated to a new system that uses a relational database, the ETL tool should be executed by setting the access method to the Unix file as described above. Thus, Unix file data can be migrated into the relational database (see, for example, Non-Patent Documents 3 and 4).

Even a database that has a function (data federation) that transparently processes multiple databases and handles it as a single virtual database can be configured in a simple table format by applying the data federation function to a Unix file. Any Unix file can be accessed (see Non-Patent Document 5, for example).
Analysis portal creation and practical use of ETL tools-@IT, ITmedia Corporation Yoko Eguchi / Hideki Uchiyama (Nihon Unisys, Ltd.), http://www.atmarkit.co.jp/fdb/rensai/sqls_analysis05/sqls_analysis05_01. html Oracle System Design, Dave Ensor / Ian Stevenson, Translated by Toru Miyahara O'Reilly Japan, ISBN4-900900-46-X Informatica: Informatica: Products-PowerExchange, http://www.informatica.jp/products/powerexchange/default.htm Development of open source ETL tool for open source RDBMS, Akio Hirai (IAF Consulting Co., Ltd.), Information-technology Promotion Agency, Incorporated Administrative Agency, http://www.ipa.go.jp/about/jigyoseika/05fy- pro / open / 2005-456d.pdf WebSphere Federation Server, IBM, http://www-06.ibm.com/jp/software/websphere/ii/pdf/fs_rs_dep.pdf

  In the ETL tool described above, it is possible to extract data from a Unix file and write it out to a part of a table included in a relational database. However, to run an application that uses data in a Unix file that was running on an old system (hereinafter referred to as a “legacy app”) on a new system that uses a relational database, the legacy app must be modified. Had to be remade to use a relational database.

  In particular, legacy applications used in systems that started operation in the 1980s and early 1990s were created before the establishment of the object-oriented method, and have a logic configuration that is difficult to reuse in the new system. There are many cases. In addition, legacy applications that access Unix files are often created in a form that specializes in the data structure inside the Unix file, and if the data structure changes, the legacy application must also be changed.

  At least in the new system using the relational database, in order to realize the same function as the old system for the Unix file, the ETL tool is used to convert and migrate the Unix file of the old system into the relational database of the new system. Therefore, it was necessary to create a new application that can access the relational database of the new system, which performs the same function as the function that the legacy application that accesses the original Unix file realized.

  On the other hand, if it is assumed that the legacy application is operated as it is, it is necessary to consider the synchronization of the legacy application that uses the Unix file and the application of the new system that uses the relational database, so the ETL tool is operated and converted each time. Therefore, there is a problem that it is difficult to synchronize when rewriting occurs in both cases, as well as a function to store in the relational database and a tool for reverse migration from the relational database to the Unix file.

  In the relational database having the data federation function described above, it is necessary that the Unix file to be read has a simple structure like a comma-separated table format. Therefore, in order to read a Unix file composed of C language structure arrays and bit fields used by legacy applications, it is necessary to add a dedicated Unix file access program. There was also a need to reduce the burden.

  The present invention solves the problems of the prior art as described above, and its purpose is to integrate the Unix file used by the legacy application into the relational database of the new system as a virtual table or virtual column. The new system can be operated on the new system without modifying the legacy application, reducing the man-hours for creating applications and improving productivity, and reusing high-quality applications that have been used and operated on the old system. Is to improve the quality.

  Another object of the present invention is to use reverse Polish notation to specify columns and rows even if a Unix file used by a legacy application has a complicated format such as a C structure array or bit field. By using a formula that uses, without creating a dedicated Unix file access program, the data inside the Unix file can be accessed from a relational database, so that the data structure inside the Unix file is not specialized This makes it possible to create an application and contributes to the improvement of productivity.

  In order to achieve the above object, one embodiment of the present invention is an information processing system having a Unix file and a relational database, and the relational database does not have an entity as a column, and other columns, other A virtual column that uses the actual data of the table column or file as its own data, and has no entity for all or part of the table, and the virtual column is part of the column, or the data of another table or file itself A virtual table, definition storage means for storing definition information for defining which other table, column, or file entity data is assigned to at least one of the virtual columns and virtual tables, and the definition Based on the information, the virtual column contains other table column entities Allocate data, open the file without modifying the Unix file, and assign all or part of it as the whole or part of the virtual table, the virtual column, or the virtual column cell. And an assigning unit that takes in the table or a part of the table into the relational database by accessing in response to the read / write request.

  In this way, by assigning and accessing the contents of a Unix file to a virtual column etc. in a relational database, operations such as reading and writing to the Unix file from a legacy application are reflected in the virtual column etc. in the corresponding relational database, On the other hand, the virtual columns in the relational database are not only referred to from the new system application (also referred to as “new application”), but are also reflected in the corresponding Unix file if an operation such as change is performed. The For this reason, the data of the Unix file for allocation can be shared between the old and new applications, the legacy application can be used without modification, and the existing Unix file can be accessed from the relational database. It is possible to escape from the structural constraints, expanding the use and contributing to the improvement of application productivity.

  As described above, in the present invention, the Unix file used by the legacy application is integrated into the relational database of the new system as a virtual table or virtual column so that the legacy application can be operated on the new system without modification. It is possible to reduce the man-hours for creating an application and improve productivity.

  A plurality of best embodiments for carrying out the present invention for integrating a relational database and a Unix file will be described below with reference to the drawings. Note that assumptions common to the explanation in the background art and problems are omitted as appropriate.

First, terms used in the present application will be described.
(1) Unix file A file stored in a directory on the Unix file system that has a tree structure. In this application, internal data consists of an array, structure array, and bit field, and is accessed from a legacy application. Refers to the file that was being saved.
(2) Legacy application (legacy application)
A program written in the C language or fortran that was created in the 1980s and early 1990s, and was created before the establishment of object orientation, so it often has a configuration or logic that is difficult to reuse. .
(3) Virtual column A column that does not have a data entity, and data such as a column of another table or data of a Unix file is assigned to the data entity.
(4) Virtual table A table that does not have an entity as a table but has a virtual column inside.
(5) Bit field A single storage unit (all words, 32 bits) defined in the processing system is a set of adjacent bits divided into multiple, and a numerical value that can be expressed in several bits is expressed in a bit field. By doing so, the capacity of the main memory or shared memory can be saved.

[1. First Embodiment]
In the first embodiment, a Unix file is integrated into a relational database so that the Unix file can be used as it is without import or language conversion, and can be integrated as a column in the table by a function that handles virtual columns. This is an example.

[1-1. Configuration of First Embodiment]
FIG. 1 is a diagram showing a configuration of a first embodiment of the present invention that integrates a relational database and a Unix file. As shown in this figure, the first embodiment is an information processing system having a relational database 1, a Unix file (Unix file group) 2, and an application (application group) 3 (hereinafter referred to as “this system”). It is.

  Among these, the relational database 1 has a normal table 11 and a virtual table. The virtual table includes a first virtual table 12 to which the normal table 11 that is not a virtual table is assigned and a second virtual table to which the Unix file is assigned. The second virtual table to which the Unix file is assigned includes the virtual table 13 to which the entire Unix file is assigned, the virtual table 14 to which the Unix file is assigned to the column, and the Unix file as the cell assignment destination. And a virtual table 15 to be

  The Unix file 2 includes a Unix file 25 in which the entire internal data represents rows and columns, a Unix file 26 in which the internal data represents columns, and the internal data represents part of the data in the rows and columns. There is a Unix file 27.

  The application 3 includes an application that uses the Unix file that has been operating in the old system, that is, the legacy application 18, and an application that uses the relational database 1 that operates in the new system, that is, the new application 19. Among these, the legacy application 18 uses the Unix file access processing unit 181 to access structured data inside the Unix file.

On the other hand, the new application 19 can operate the table inside the relational database 1 using the table data operation processing unit 20 of the relational database 1 and operates the data inside the virtual table using the virtual column allocation processing unit 21. be able to.
Next, each part in FIG. 1 will be described in more detail.

[1-1-1. Database details
The relational database 1 stores a plurality of tables as illustrated in FIG. A table is tabular data composed of rows and columns, and one or more tables are stored in a relational database. Each table is given a name (for example, [TABLE-A]) that is uniquely identified in the relational database, thereby identifying each table. These names may be any names that can uniquely identify the table within the relational database, and may be given numbers.
[1-1-2. Normal table)
A normal table in the relational database 1 stores a plurality of columns as shown in FIG. 2 (1), but each column plays a role of a column in the table and is stored in one or more in the table. Has been. Each column is given a name (for example, [COL-A]) for uniquely identifying in the table, thereby identifying each column. This name only needs to be able to uniquely identify the column within the table, and may be given a number.

[1-1-3. (Virtual table)
Further, the virtual table in the relational database 1 stores one or a plurality of virtual columns as shown in FIG. Such a virtual table is also a kind of table, and one or a plurality of such virtual tables are stored in the relational database and given a name (for example, [VTABLE-B]) for uniquely identifying. A virtual table can also be accessed as a table inside a relational database in the same way as a normal table, but each virtual table is accompanied by a column attribute table that describes a virtual column assignment destination.

  FIG. 3 is a conceptual diagram illustrating such a virtual column data allocation destination. That is, unlike a normal column, a virtual column does not have its own data inside the table. For example, the virtual column 32 included in the virtual table 31 assigns the data of the other column [COL-C] in the same table as its own data, and the virtual column 33 is the column of the table 36 to which it does not belong [ VCOL-B] is allocated, the virtual column 34 allocates the data array of the Unix file 42 as its own data, and the virtual column 35 is a predetermined file in the Unix file 43, the Unix file 44, the Unix file 45, and the Unix file 46. Are assigned as data of their own cells.

  Further, for example, each data value included in the Unix file 41 is assigned as a row and a column to each virtual column included in the virtual table 36.

[1-1-4. Column attribute table)
The virtual column allocation destination information as described above is described in a column attribute table (for example, 37) attached to the virtual table, and the virtual column allocation processing unit 21 stores the allocation destination data according to this column attribute table. Assign to a virtual column. That is, the column attribute table is a definition storage unit that stores definition information that defines which other column's entity data is allocated to each virtual column.

  Information indicating whether the table is a normal table or a virtual table including a virtual column is stored in a column attribute table as illustrated in FIG. Such a column attribute table includes a column name (for example, “virtual column [VCOL-D]”), a column variable type (“column type” shown in the table of FIG. 4), and a table name to which a virtual column is assigned. ("Assignment destination name" shown in the table of FIG. 4), column name, and Unix file name ("assignment destination column / file name" shown in the table of FIG. 4) are described.

  Here, the Unix file 2 shown in FIG. 1 is a file stored in a directory on the Unix file system having a tree structure. In the first embodiment, the Unix file 2 stores therein data to be read / written / added / deleted from the legacy application 18. Data in such a Unix file 2 is composed of rows and columns, or rows or data alone, and is in the form of a kind of table.

  When the legacy application 18 accesses the data in the Unix file as described above, the data is accessed using the Unix file access processing unit 181, and a row and a column, or a row or column using a C language array or the like. Specify data and perform data operations. For the Unix file 2 to which the virtual column is assigned, the content of the file that was imported by opening the Unix file becomes the actual data of the virtual column, and reading / writing / adding / deleting data from / to the virtual column It is also performed on the corresponding data in the Unix file.

  The legacy application 18 that uses the Unix file that has been operating in the old system has a Unix file access processing unit 181 that accesses the Unix file having data therein, and the Unix file access processing unit 181 causes the Unix file to be accessed. Read / write / add / delete internal data. An example in which the Unix file access processing unit 181 is implemented using a file access function provided in basic software represented by an OS (Operating System) is also conceivable.

  The new application 19 that accesses the relational database 1 has a database access processing unit 191 that accesses the relational database. The database access processing unit 191 operates a table stored in the relational database using the table data operation processing unit 20 of the relational database, and converts the data in the virtual table using the virtual column allocation processing unit 21. Reading, writing, adding, and deleting can be performed.

[1-2. Operation of First Embodiment]
The first embodiment configured as described above operates as follows. First, as an overview, the virtual column allocation processing unit 21 allocates the actual data of other columns to the virtual column based on the attribute table, and opens the file without modifying the Unix file, and the whole or a part thereof , A virtual table, a virtual column, or a cell of a virtual column are allocated as a whole or a partial entity and accessed according to a corresponding read / write request to be included as a table or a part of a table in a relational database Capture as you do.
More specifically, the processing is as follows.

[1-2-1. Operation from the new application 19)
First, in FIG. 5, in the table data operation processing unit 20, for a virtual table having a virtual column to which the Unix file 2 is assigned, data in the virtual column is transferred from the new application 19 operating in the new system. It is a flowchart at the time of operation.

  In this processing procedure, first, when an operation request for table data is received from the new application 19, it is determined from the column attribute table whether the table includes a virtual column (S101). If a virtual column is included (S101), it is determined from the column attribute table whether the virtual column assignment destination is a Unix file (S102).

  If the virtual column assignment destination is a Unix file (S102), it is determined whether or not the Unix file has been opened (S103). If the Unix file is not opened (S103), the file name of the Unix file is acquired from the column attribute table, and the Unix file is opened (S104). At this time, the open method may be either a method using a file descriptor or a file mapping for allocating a file to a memory. When the Unix file is opened, it is determined how to assign the Unix file to the virtual table (S105, S106).

  That is, if the Unix file is assigned to the entire virtual table (S105), the data in the Unix file corresponding to the row and column passed from the application is specified (S107). Typically, the sizes of the variable types of the columns constituting the virtual table are enumerated to obtain a column size for one row, thereby specifying the rows and columns in the Unix file. The rows and columns specifically used in this way have the same size as the rows and columns used when the legacy application 18 accesses the Unix file. The operation requested by the application is executed on the data specified as described above (S110).

  If the Unix file is allocated to one of the virtual columns, that is, one column (S106), the data in the Unix file corresponding to the row specified by the application is specified (S108). The data is specified by applying the variable type array of the columns that make up the virtual table to the entire data in the Unix file. The size of the specified data is a variable and a size used when the legacy application 18 accesses the Unix file. Then, the operation requested by the application is executed on the data specified in this way (S110).

  When the Unix file is assigned to one cell of the virtual column, the entire data in the Unix file is specified as data (S109). The identified data is the same as the data used by the legacy application 18 when accessing the Unix file. Then, the operation requested by the application is executed on the data specified in this way (S110).

[1-2-2. Operation from legacy application 18)
Next, FIG. 6 is a flowchart for operating a Unix file from the legacy application 18. In this processing procedure, it is checked whether or not the Unix file has been opened (S121). If the Unix file has not been opened (S121), the Unix file is opened (S122), and the data corresponding to the rows and columns is stored in the Unix file. After specifying (S123), an operation is performed on the data (S124).

  The rows and columns used specifically are the same size as the rows and columns used when accessing the virtual table with the new application 19 described above, the data indicated by the rows and columns specified in the legacy application 18, and the new application The data indicated by the row and column specified in 19 is the same. Note that this processing can be used without modification from the processing at the time of operating in the old system.

[1-3. Effects of the first embodiment]
According to the first embodiment as described above, when a legacy application 18 performs a read / write / add / delete operation on a Unix file, the contents of the virtual column to which the Unix file is assigned are also manipulated. Therefore, the data of the virtual table inside the relational database is changed, and the changed contents can be referred to from an application accessing the relational database. And when the new application 19 that accesses the relational database performs read / write / add / delete operations on the virtual column data to which the Unix file is assigned, the contents of the Unix file are also manipulated. The contents can also be referred to in the legacy application 18.

  As described above, since the legacy application 18 and the new application 19 can share the data of the Unix file, the legacy application 18 can be used without modification, and the data of the Unix file can be accessed from the relational database. Since it is possible to escape from the physical data structure, it can contribute to the improvement of application productivity.

  In other words, the data in the Unix file can be accessed from the application for the new system that accesses the relational database, so that the data between the new system application and the legacy application can be shared. Expansion can also be done.

[2. Second Embodiment]
The second embodiment deals with reverse Polish assignment and dynamic columns as the virtual column assignment method, which will be described with reference to FIGS. 1, 3, and 7 to 9, but is the same as the first embodiment. The same reference numerals are given to the configurations of, and duplicate descriptions are omitted.

  As an outline of the second embodiment, the definition information has a calculation formula in which address data indicating the location of entity data to be allocated to a virtual column is described in reverse Polish notation, and the virtual column allocation processing unit 21 has such a definition. Based on the calculation formula of information, the actual data of the corresponding address data is converted into a representation format as a virtual column, and assigned as a row and a column of the table.

[2-1. Configuration of Second Embodiment]
The configuration of the second embodiment conforms to that of the first embodiment (FIGS. 1 and 3). However, as a difference from the first embodiment, in the column attribute tables 37 and 38 (FIG. 3), data is stored in virtual columns. The formula expressed in reverse Polish notation is used for assignment.

  That is, FIG. 7 exemplifies the column attribute table in the second embodiment, and unlike the first embodiment, describes a calculation formula expressed in reverse Polish notation. In such a second embodiment, the four arithmetic operations of the reverse Polish notation described in the calculation formula are performed on the row number, the relative address of the data of the assignment source is obtained, and the relative address corresponding to each row of the virtual column is obtained. Apply to allocation source data to get virtual column data.

[2-2. Operation of Second Embodiment]
In the second embodiment configured as described above, FIG. 8 is a flowchart for assigning data to a virtual column using a calculation described in reverse Polish notation for a virtual table having a virtual column. .

  That is, first, a calculation formula is acquired from the column attribute table (S131). If the calculation formula is not described in reverse Polish notation (step S132), it is converted into reverse Polish notation (S133). Then, the relative address is calculated from the number of rows using the reverse Polish notation (S134), and the obtained relative address is assigned to the original data to be the virtual column data (S135).

  As a specific example, as shown in FIG. 9, a calculation formula for allocating a virtual column for each member of a structure of a structure array is given to data 61 described in a C structure array and one array corresponds to one record. For example, by setting in the column attribute table 62, the data described in the structure array can be used as the data of the virtual table 63.

[2-3. Effect of Second Embodiment]
As described above, according to the second embodiment, a virtual column is assigned to each member of a structure of the structure array even for data described in a C structure array and one array corresponds to one record. By setting the calculation formula in the column attribute table, the data described in the structure array can be used as the data of the virtual table. For this reason, it is possible to refer to structure array data in a Unix file, which was accessible only with a C structure array, as one of the tables in the relational database. It becomes easy to utilize the data.

[3. Third Embodiment]
Next, a third embodiment according to the present invention employs a static column as a virtual column allocation method, and will be described with reference to FIGS. 1, 3, and 10 to 12. In addition, the same code | symbol is attached | subjected to the structure same as 1st Embodiment and 2nd Embodiment, and the overlapping description is abbreviate | omitted.

  As an outline of the third embodiment, the virtual column allocation processing unit 21 calculates in advance address data indicating the location of the entity data using a calculation formula using reverse Polish notation as shown in the second embodiment. The calculation results are stored and held in cell units of the table, and the calculation results stored and held as described above are read out and used at the time of assignment to the virtual column.

[3-1. Configuration of Third Embodiment]
The configuration of the third embodiment is the same as that of the second embodiment (FIGS. 1 and 3). However, as a difference from the second embodiment, a calculation formula for each row is added to the column attribute table of the virtual table or the virtual table. Add an item to store the relative address of the allocation source data calculated using

  FIG. 10 shows a column attribute table when the storage destination of the relative address is the column attribute table. FIG. 10 is a column attribute table of a virtual table when the virtual table 63 of FIG. 9 of the second embodiment is applied to the third embodiment. The item for storing the calculation result is a field entitled “Relative Address”, which stores the relative address calculated for each row.

  On the other hand, FIG. 11 illustrates a virtual table when the storage destination of the relative address is inside the virtual table. In this case, the storage column of the relative address corresponding to the virtual column is set and used when acquiring the virtual column assignment destination data.

[3-2. Operation of the third embodiment]
In the third embodiment configured as described above, a processing procedure for allocating data to a virtual column using a relative address described in the column attribute table or the virtual table for a virtual table having a virtual column Is shown in the flowchart of FIG. That is, the relative address of the row from which data is acquired from the column attribute table or the virtual table is acquired (S151), and the relative address is allocated from the allocation destination data to the virtual column (S152).

[3-3. Effects of the third embodiment]
According to the third embodiment, the storage capacity for storing the relative address is required as compared with the second embodiment, but the relative address is calculated in advance and stored in the column attribute table or the virtual table. Thus, the overhead of spending time each time calculating the relative address can be reduced, and the speed when accessing the virtual table from the application using the relational database can be improved.

[4. Fourth Embodiment]
Next, a fourth embodiment according to the present invention uses a bit field as a virtual column allocation method, and will be described with reference to FIGS. 1, 3, and 13 to 15. In addition, the same code | symbol is attached | subjected to the structure same as 1st Embodiment, and the overlapping description is abbreviate | omitted.

  As an outline of the fourth embodiment, the definition information indicates how to allocate the entity data to be assigned to the virtual column to the row and column of the table for each field configured in bit units. Based on such definition information, the unit 21 classifies the corresponding entity data for each field in bit units, and assigns it to the rows and columns of the corresponding table.

[4-1. Configuration of Fourth Embodiment]
The configuration of the fourth embodiment is similar to that of the second embodiment (FIGS. 1 and 3). However, as a difference from the second embodiment, the allocation source data is in the C language as shown in FIG. It is composed of a structure including a bit field, and each bit constituting the bit field is assigned to a virtual column.

  And the column attribute table in 4th Embodiment is illustrated in FIG. That is, unlike the second embodiment, items of bit position and bit size are added to the column attribute table. In the fourth embodiment, the bit of the bit position and the bit size described in the column attribute table are assigned to the virtual column for the relative address data obtained by performing the four arithmetic operations described in the calculation formula. This is the destination data.

[4-2. Operation of the fourth embodiment]
In the fourth embodiment configured as described above, a processing procedure for allocating data to a virtual column in a case where data configured by a bit field is used as a virtual column allocation source is shown in a flowchart of FIG.

  That is, first, a calculation formula is obtained from the column attribute table (S161), and if the calculation formula is not described in reverse Polish notation (step S162), it is converted into reverse Polish notation (S163). Then, the relative address is calculated from the number of rows using reverse Polish notation (S164), and then the bit position and the bit size are acquired from the column attribute table (S165), and exist in the relative address obtained by these calculations. Data of the bit position / bit size of the data is acquired and used as virtual column data (S166).

[4-3. Effects of the fourth embodiment]
According to the fourth embodiment as described above, by assigning a virtual column for each bit to the data constituted by the bit field, the data constituting the bit field can be used as the data of the virtual table. it can. As a result, for example, bit field data in a Unix file that can be accessed only with a bit field in C language can be referred to as one of the tables in the relational database, and data resources from the old system era can be saved without unnecessary man-hours. Utilization is also easy.

[5. Fifth Embodiment]
Next, in the fifth embodiment according to the present invention, the virtual column allocation method is an arbitrary bit length, and will be described with reference to FIGS. 1, 3, 16, and 17. FIG. In addition, the same code | symbol is attached | subjected to the structure same as 2nd Embodiment, and the overlapping description is abbreviate | omitted.

  As an outline of the fifth embodiment, the definition information indicates how to assign entity data using an array configured with an arbitrary bit length to a row and a column of a table, and a virtual column allocation processing unit 21 assigns a bit-length array corresponding to the entity data or each element thereof to the rows and columns of the table based on the definition information.

[5-1. Configuration of Fifth Embodiment]
The configuration of the fifth embodiment is the same as that of the second embodiment (FIGS. 1 and 3). However, as a difference from the second embodiment, the allocation source data is composed of a plurality of arbitrary length bits. The long bit data is allocated to the virtual column, and the calculation expression expressed in the reverse Polish notation returns the relative bit position of the allocation destination data instead of the relative address as a result.

  Here, FIG. 16 is a column attribute table in the fifth embodiment. That is, unlike the second embodiment, an item of bit size is provided in the column attribute table. Further, in the fifth embodiment, the result returned by the calculation formula in reverse Polish notation is the bit position, and the data for the bit size existing in the relative bit position obtained by performing the described four arithmetic operations is stored in the virtual column. It is assigned data.

[5-2. Operation of Fifth Embodiment]
In the fifth embodiment configured as described above, a processing procedure for allocating data to a virtual column in the case where data configured with an arbitrary bit length is set as a virtual column allocation source is shown in the flowchart of FIG. .

  That is, first, a calculation formula is obtained from the column attribute table (S171), and it is determined whether or not the calculation formula is written in reverse Polish notation (S172). Conversion is performed (S173). Then, the relative bit position is calculated from the number of rows using the reverse Polish notation (S174), the bit size is acquired from the column attribute table, the data for the bit size existing in the relative bit obtained by the calculation is acquired, The data is assumed to be virtual column data (S175).

[5-3. Effects of the fifth embodiment]
According to the fifth embodiment, by assigning a virtual column for each bit to data configured with an arbitrary bit length, data configured with an arbitrary bit length is also used as data in the virtual table. It is possible to refer to data of an arbitrary bit length inside the Unix file that can be accessed only in the C language as one of the tables inside the relational database. For this reason, it becomes easy to utilize data resources from the old system era without wasteful man-hours.

[6. Sixth Embodiment]
Next, the sixth embodiment of the present invention includes an update detection function using message digest and cyclic redundancy detection, and will be described with reference to FIGS. In addition, the same code | symbol is attached | subjected to the structure same as 1st Embodiment, and the overlapping description is abbreviate | omitted.

  The outline of the sixth embodiment is that, in a relational database, a data modification detection code for detecting a code error is periodically generated and stored for data in a Unix file, and the previous data modification detection code in the next period. An update detection means is provided for detecting an update of a Unix file by comparing with.

[6-1. Configuration of Sixth Embodiment]
The configuration of the sixth embodiment is as shown in FIG. 18 in which the configuration that is characteristic of the sixth embodiment is added to the configuration of the first embodiment (FIG. 1), and is different from the first embodiment. Is the addition of a Unix file update detection processing unit 71 as the update detection means.

  The Unix file update detection processing unit 71 periodically opens the Unix file 2 to which the virtual table is assigned, and creates and stores a data modification detection code for the data in the Unix file to which the virtual column is assigned. It has a function.

  As the data alteration detection code, a message digest used for file distribution with security added on the Internet, a code error code by cyclic redundancy detection, and the like can be selected and used as appropriate. The Unix file update detection processing unit 71 determines that the data has been updated if the previously stored code and value have changed, and sends the data to the relational database 1 and the new application 19 using the relational database. It has a function to notify update.

  Here, the column attribute table in the sixth embodiment is as illustrated in FIG. 19, and in this example, unlike the first embodiment, a field of a data modification detection code (data modification code) is included. It is. In the sixth embodiment, the Unix file update detection processing unit 71 periodically stores the data modification detection code in the column attribute table as described above.

[6-2. Operation of Sixth Embodiment]
FIG. 20 shows a flowchart when the Unix file update detection processing unit 71 generates the data modification detection code of the Unix file 2 and detects the update in the sixth embodiment configured as described above.

  That is, when the Unix file update detection processing unit 71 reaches the data update detection cycle (S181), a virtual table having a virtual column is searched from the column attribute table (S182). When a virtual table is found, the virtual table allocation destination is determined (S183). If the allocation destination is a Unix file (S183), it is checked whether the Unix file has been opened (S184), and the Unix file is not opened. If so (S184), it is opened (S185).

  Then, an error code detection code is generated from the data in the opened Unix file by using message digest or cyclic redundancy detection, and used as a data modification detection code (S186). Further, the previous data modification detection code is obtained from the column attribute table (S187), and compared with the data modification detection code generated this time (S188). As a result, if the value of the data modification detection code has changed between the previous time and the current time (S188), the update detected data is notified to the relational database 1 and the new application 19 using the relational database (S189). Then, whether or not such an update is notified, the data modification code generated this time is overwritten and saved in the column attribute table (S190).

[6-3. Effects of the sixth embodiment]
According to the sixth embodiment, when the legacy application 18 updates the Unix file and the data is changed, the Unix file update detection processing unit 71 detects the change from the data modification detection code, The data change contents in the Unix file can be notified to the new application 19 and the relational database. For this reason, the degree of freedom of system configuration and application such as cooperation between the old application and the new application is improved.

[7. Seventh Embodiment]
Next, the seventh embodiment according to the present invention enables joining of tables, and will be described with reference to FIGS. In addition, the same code | symbol is attached | subjected to the structure same as 1st Embodiment, and the overlapping description is abbreviate | omitted.

  The outline of the seventh embodiment is a table joining means for responding to an access request as a single table by joining data in a plurality of tables including virtual tables or virtual columns each assigned internal data of a Unix file. It is in the point which provided.

[7-1. Configuration of Seventh Embodiment]
The configuration of the seventh embodiment is as shown in FIG. 21 in which the characteristic configuration of the seventh embodiment is added to the configuration of the first embodiment (FIG. 1), and is different from the first embodiment. A table join processing unit 81 is added as the table joining means for joining columns of a plurality of tables.

  The table join processing unit 81 acquires setting items from the view setting data 82, selects and joins arbitrary data of a plurality of tables, and displays them in a table format (hereinafter referred to as “view”). It has a function of returning to the application 19.

  Here, the structure of the view is shown in FIG. That is, a view is composed of rows and columns as in a table, but does not include data itself as in a virtual column, and data that can be selected as view data is a normal table, virtual table, and other views. It is. You can also select a virtual column that is assigned to a Unix file as view data. By using such a view, the contents of a plurality of tables can be represented by one table.

[7-2. Operation of the seventh embodiment]
FIG. 23 shows a flowchart when the table join processing unit 81 joins a plurality of tables and creates a view in the seventh embodiment configured as described above. In other words, when the creation of a view is requested by the new application 19, the table join processing unit 81 acquires the setting contents of the view from the view setting data 82 (S191). If the data to be viewed is normal table data (S192), the table data acquisition processing unit 20 described in the first embodiment is caused to perform table data operation processing (FIG. 5) (S193). At this time, if the table is a virtual table to which a Unix file is assigned, the virtual table is assigned as in the first embodiment (FIG. 5).

  If the data to be viewed is a view (S192), the table join process is recursively performed (S194). The data acquired as described above is edited into a table format (S195), and the view is returned to the application that requested the creation of the view (S196).

[7-3. Effects of the seventh embodiment]
According to the seventh embodiment, by using a view that combines a plurality of virtual tables whose allocation destination is a Unix file, the new application 19 that uses a relational database traverses a plurality of Unix files. Data can be referenced. In particular, by assigning multiple Unix files as virtual tables and creating a view, the data used in the old system can be aggregated and displayed. That is, in the legacy application 18, the aggregated contents of multiple Unix files are realized by program logic, but by using the view as described above, the man-hour for creating / modifying the application is reduced and the productivity is further improved. Is possible.

[8. Eighth Embodiment]
Next, an eighth embodiment according to the present invention is obtained by adding data equivalence / replication processing and will be described with reference to FIGS. In addition, the same code | symbol is attached | subjected to the structure same as 1st Embodiment, and the overlapping description is abbreviate | omitted.

  As an overview of the eighth embodiment, a plurality of computers, which are information processing systems storing tables, are connected to each other via a communication network and assigned to a table stored in the own computer at least on one computer. The data modification detection code that detects the sign error is periodically generated and stored for the data in the Unix file, and the data of the Unix file is compared with the previous data modification detection code in the next period. Update detection means for detecting an update is provided. Further, when the update detection unit detects an update of the internal data to each computer, the update information indicating the detected contents is notified to other computers, and the update information notified from the other computers A data duplicating means is provided for reflecting in the Unix file assigned to the table stored in the own computer.

[8-1. Configuration of Eighth Embodiment]
The configuration of the eighth embodiment is obtained by adding the Unix file update detection processing unit 71 shown in the sixth embodiment and a single configuration specific to the eighth embodiment to the configuration of the first embodiment (FIG. 1). This is as shown in FIG. That is, as a difference from the first embodiment, a relational database 1, a Unix file 2, an application 3, and a set are arranged in each of the computer A (91) and the computer B (92). The computer B is connected by a network 93, and a data replication processing unit 94 and a data replication processing unit 95 are added to the relational databases 1 of the computers A91 and B92.

  Further, the relational database 1 of the computer A has a Unix file update detection processing unit 71 according to that shown in the sixth embodiment as the updating means, and the data updated in the relational database of the computer A is a network. To the relational database of computer B.

  That is, the data replication processing unit 94 of the computer A receives the table update content from the table data operation processing unit 22 and transmits it to the data replication processing unit 95 of the computer B through the communication network 93 such as a LAN. The data replication processing unit 95 of the computer B transmits the table update content received from the data replication processing unit 94 of the computer A via the network 93 to the table data operation processing unit 22 to update the table content.

  Also, even when the target updated by computer A is a Unix file, the Unix file update detection processing unit 71 detects the update and transmits the update contents of the virtual table to the data replication processing unit 94 of computer A, and the data of computer A The replication processing unit 94 transmits the data to the data replication processing unit 95 of the computer B through the network 93. The data replication processing unit 95 of the computer B transmits the received virtual table update content to the table data operation processing unit 22 to update the content of the Unix file.

[8-2. Operation of Eighth Embodiment]
Next, in the processing procedure according to the eighth embodiment, FIG. 25 is a flowchart of the data duplication processing of the computer A that transmits the updated contents of the table to other computers. That is, when the contents of the table data are updated, the data replication processing unit 94 of the computer A receives the update data from the table data operation processing unit 22 (S201). Similarly, when the contents of the Unix file that is the allocation source of the virtual table are updated, the data replication processing unit 94 of the computer A is handed over the update data from the table data operation process (S201).

  In any case, the data replication processing unit 94 of the computer A is connected to the data replication processing unit 95 of the computer B via the communication network 93 (S202). When this connection is accepted, the data replication of the computer B is performed. Update data is transmitted to the processing unit 95 (S203).

  FIG. 26 is a flowchart of the data replication process in the computer B when the update data of the table as described above is received. That is, when a connection request is received from the data replication processing unit 94 of the computer A via the communication network 93, the data replication processing unit 95 of the computer B accepts the connection (S204). When update data is transmitted from the replication processing unit 94, the update data is received (S205).

  Then, the update data received in this way is transferred to the table data operation processing unit 22, and the table data is updated (S206). At this time, if the allocation destination of the virtual table is a Unix file, the table data operation processing unit 22 opens the Unix file and updates the Unix file.

[8-3. Effects of the eighth embodiment]
As described above, according to the eighth embodiment, a relational database in which a Unix file is designated as a virtual table allocation destination is arranged on a plurality of computers, so that an update in the Unix file is detected and updated. The contents of a Unix file can be replicated between computers by updating the virtual table in the relational database of the computer that was sent to the computer and received.

  That is, in the old system in which the legacy application 18 was operating, even if there was one having a function of sharing a disk or memory between the computer and the computer, if the eighth embodiment is applied, the old system It is possible to simulate the shared memory and the shared disk that have been operating in the system, and it is not necessary to modify the legacy application 18, so that the man-hours for modification can be greatly reduced.

[9. Other embodiments]
In addition, this invention is not limited to the said embodiment, The thing illustrated below and other embodiment other than that are included. For example, the configuration, the flowchart of the processing procedure, the data structure, and the like shown in the drawings are merely examples, and can be appropriately changed. Examples of such changes also belong to the scope of the present invention. is there.

  For example, in the eighth embodiment (FIG. 24), the change to the Unix file by the legacy application 18 of the computer A is detected by the Unix file update detection processing unit 71 and is reflected in the computer B. By providing the detection processing unit in the computer B, it is also possible to reflect the change to the Unix file by the legacy application 18 of the computer B on the computer A.

The figure which shows the structure of 1st Embodiment of this invention. The figure which shows an example of the data structure of table data in 1st Embodiment of this invention. The figure which shows an example of the relationship and structure of a virtual table and an allocation destination in 1st Embodiment of this invention. The figure which shows an example of the data structure of a column attribute table in 1st Embodiment of this invention. The flowchart which shows the outline | summary of the table data operation processing procedure in 1st Embodiment of this invention. 5 is a flowchart showing an outline of a Unix file data operation processing procedure in the first embodiment of the present invention. The figure which shows an example of the data structure of the column attribute table which added the item of the calculation formula in 2nd Embodiment of this invention. The flowchart which shows the outline | summary of the virtual column allocation processing procedure using a calculation formula in 2nd Embodiment of this invention. The figure which shows an example allocated to a virtual table from the data of C language structure array in 2nd Embodiment of this invention. The figure which shows an example of the data structure of the column attribute table which added the relative address item of the allocation destination in 3rd Embodiment of this invention. The figure which shows an example of the data structure of the virtual table which added the relative address item of the allocation destination in 3rd Embodiment of this invention. The flowchart which shows the outline | summary of the virtual column allocation processing procedure which uses the relative address preserve | saved in the column attribute table in 3rd Embodiment of this invention. The figure which shows an example of the structure of C language containing a bit field in 4th Embodiment of this invention. The figure which shows an example of the data structure of the column attribute table which made the allocation body the structure containing a bit field in 4th Embodiment of this invention. The flowchart which shows the outline | summary of the virtual column allocation process procedure which made the structure containing a bit field the allocation destination in 4th Embodiment of this invention. The figure which shows an example of the data structure of the column attribute table which made the allocation object the structure containing arbitrary bit length data in 5th Embodiment of this invention. The flowchart which shows the outline | summary of the virtual column allocation processing procedure which made the structure containing arbitrary bit length data the allocation destination in 5th Embodiment of this invention. The block diagram which shows the integration method of the relational database which added the Unix file update detection process, and the Unix file in 6th Embodiment of this invention. The figure which shows an example of the data structure of the column attribute table which added the data modification code | symbol of the Unix file in 6th Embodiment of this invention. The flowchart which shows the outline | summary of the Unix file update detection processing procedure in 6th Embodiment of this invention. The block diagram which shows the integration method of the relational database and Unix file which added the table joining process in 7th Embodiment of this invention. The figure which shows an example of a table coupling | bonding in 7th Embodiment of this invention. The flowchart which shows the outline | summary of the table joint process procedure in 7th Embodiment of this invention. The block diagram which shows the integration method of the relational database and Unix file which were equipped with the data replication process in 8th Embodiment of this invention. The flowchart which shows the outline | summary of the data replication process sequence by the side of data transmission in 8th Embodiment of this invention. The flowchart which shows the outline | summary of the data replication process procedure by the side of data reception in 8th Embodiment of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Relational database 2 ... Unix file 3 ... Application 11 ... Normal table 12 ... Virtual table 18 ... Legacy application (legacy application)
19 ... New system application (new app)
20 ... Table data operation processing unit 21 ... Virtual column allocation processing unit 71 ... Unix file update detection processing unit 81 ... Table join processing units 94, 95 ... Data replication processing unit

Claims (9)

An information processing system having a Unix file and a relational database,
The relational database is
A column that constitutes a relational database table, which does not have an entity as a column, another column, a virtual column whose own data is a column of another table or a file entity data,
A virtual table that has no entity for all or part of the table, the virtual column is part of a row, or the data of another table or file is its own data;
Definition storage means for storing definition information that defines which other table, column, or file entity data is assigned to at least one of each virtual column and virtual table;
Based on the definition information, actual data of a column of another table is allocated to the virtual column, and the Unix file is opened without altering the entire or a part of the file, and the virtual table, the virtual column, Or allocation means for allocating as a whole or a part of a virtual column cell and accessing it according to a corresponding read / write request so as to be included in a relational database as a table or a part of a table; ,
An information processing system comprising: The definition information has a calculation formula in which address data indicating the location of entity data assigned to a virtual column is described in reverse Polish notation,
The allocating means is configured to allocate the actual data of the corresponding address data as the row and column of the table by converting the actual data of the address data into the representation format as the virtual column based on the calculation formula of the definition information. The information processing system according to claim 1. The assigning means includes
Using the calculation formula using the reverse Polish notation, the address data indicating the location of the entity data is calculated in advance, and the calculation result is stored and held in cell units in the table.
The information processing system according to claim 2, wherein the calculation result stored in the memory is read and used when allocating to a virtual column. The definition information represents how to assign to the rows and columns of the table for each field configured in bit units for the entity data to be assigned to the virtual column,
The allocation unit is configured to divide the corresponding entity data for each bit field based on the definition information, and to allocate the data to a row and a column of the corresponding table. The information processing system according to any one of the above. The definition information represents how entity data using an array configured with an arbitrary bit length is allocated to a row and a column of a table,
5. The configuration according to claim 1, wherein the assigning unit is configured to assign the bit length array corresponding to the entity data or each element thereof to a row and a column of a table based on the definition information. The information processing system according to any one of the above. The relational database periodically generates and stores a data modification detection code for detecting a code error for the data in the Unix file, and compares it with the previous data modification detection code in the next cycle. The information processing system according to any one of claims 1 to 5, further comprising update detection means for detecting an update of the Unix file. A table joining means for responding to an access request as a single table by joining data in a plurality of tables including virtual tables or virtual columns each assigned with internal data of a Unix file. Item 7. The information processing system according to any one of items 1 to 6. A plurality of computers that store a table and are the information processing system according to any one of claims 1 to 7 are connected to each other via a communication network,
In at least one computer, a data modification detection code for detecting a code error is periodically generated and stored for the data in the Unix file assigned to the table stored in the computer, and next time An update detection means is provided to detect the update of the Unix file by comparing with the previous data modification detection code in the cycle,
When the update detection unit detects an update of the internal data, it notifies the update information indicating the detected contents to other computers, and the update information notified from the other computers is stored in the own computer. An information processing system characterized in that each computer is provided with a data replication means to be reflected in the Unix file assigned to the table. An information processing system control method having a Unix file and a relational database,
In the relational database,
A column that constitutes a relational database table, which does not have an entity as a column, another column, a virtual column whose own data is a column of another table or a file entity data,
A virtual table that has no entity for all or part of the table, the virtual column is part of a row, or the data of another table or file is its own data;
As well as
For at least one of the virtual columns and virtual tables, definition information defining which other table, column or file entity data is allocated is stored in advance in a predetermined definition storage means,
Based on the definition information, actual data of a column of another table is allocated to the virtual column, and the Unix file is opened without altering the entire or a part of the file, and the virtual table, the virtual column, Alternatively, an allocation process that allocates a virtual column cell as an entire or partial entity and accesses it according to the corresponding read / write request so as to be included in the relational database as a table or a part of the table is performed. A control method of an information processing system, characterized by being executed.

Images