JP7245727B2 - Data management and storage method, data management and storage device, and computer program for implementing them - Google Patents

Description

The present invention relates to a data management and storage method, a data management and storage device, and a computer program for implementing these data management and storage method and data management and storage device. The present invention relates to a data management and storage method and a data management and storage device capable of ensuring integrity, and a computer program for implementing these data management and storage method and data management and storage device.

As an accounting system, migration to ERP (Enterprise Resource Planning) system represented by SAP, migration from mainframe to distributed system (downsizing) is seen, and many distributed DB (Data Base) application systems are adopted. It is At first, it was thought that long-term storage of transaction details, etc., as stipulated by the tax law, would be possible with the transition to the ERP system.

However, as the amount of information to be stored increases, the information storage resource is put under pressure, and the past information is saved in an MT (Magnetic Tape) or the like. Accounting information is obligated to be stored for seven years under tax law, but most companies can only access information for one to two years online, and information prior to this is stored offline, such as MT. Therefore, the national tax examiners have to output the necessary data in batches from the offline system for information that is not available on the online system, import this into database management software such as Microsoft's ACCESS, and conduct an audit. there is

In addition, it is necessary to take sufficient measures to prevent falsification or leakage of important information such as accounting information. need to be taught. Therefore, while enabling high-speed access and high-speed search, it is necessary to sufficiently ensure security and prevent data falsification by means of encryption.

Here, in Patent Document 1, users can access the system without restriction even during the backup process, and a snapshot backup image that does not require reconfiguration is created on MT as a quick and consistent backup. A technique is disclosed that enables the creation of

In addition, Patent Document 2 discloses a snapshot management method that uses differential information with high disk usage efficiency, does not degrade write performance, and has a restoration function that minimizes operation stop time and operation restart time. A functional snapshot management system is disclosed.

However, Patent Documents 1 and 2 do not consider the above-mentioned characteristics of accounting information. It does not disclose how to prevent data falsification and ensure security by encryption.

The applicant has proposed Patent Document 3 as a solution to such problems. As a result, while reducing resources by efficiently compressing data, it is possible to store a large amount of information such as transaction history and store it for a long time, as well as enable high-speed access and high-speed search. Prevention and ensuring security can be enabled.

Data of a basic configuration as shown in FIG. 1 is obtained by the technique of Patent Document 3. FIG. In the figure, 60 is each transaction data, 62N, 62N+1, 62N+2, .

Japanese Patent Publication No. 2001-520779 JP 2010-79331 A Japanese Patent No. 5844554

However, it has not been possible to secure proof of public existence of data or to detect deletion of data to ensure proof of integrity. That is, in the technique proposed in Patent Document 3, each snapshot is compressed and encrypted in units of blocks, and although there is no data change logic, there is no public proof of data existence. Also, for example, the snapshot 62N on day N and the snapshot 62N+1 on day N+1 are not chained and could not be proven not to be deleted.

The present invention was made in order to solve the above-mentioned conventional problems. It is to secure public existence proof of data based on the XAdES file and to secure completeness proof without omission in a series of data. is the subject.

The present invention provides a data management and storage method for periodically storing information in a managed database in which hourly data that occurs in time series is stored in a snapshot, wherein the hourly data, Then, the time unit data before the current time unit is snapshotted, a manifest file containing hash values of the snapshots of the continuous multiple time unit data is created, and the manifest file is sent to the time stamp server. The problem is solved by sending an XAdES file of a predetermined time unit to which an electronic signature and a time stamp are added by the time stamp server.

Here, the hash value of the time unit data before the time unit is snapshotted together with the time unit data, and the snapshot is sent to the time stamp server to obtain the time stamped snapshot. be able to.

The present invention also provides a data management storage device that periodically saves information in a managed database in which hourly data generated in chronological order is stored as snapshots. means for creating a snapshot of data and data in time units prior to the current time unit; means for creating a Manifest file containing hash values of the snapshots of the consecutive multiple time units of data; and means for sending the Manifest file to a time stamp server, and the time stamp server obtains an XAdES file of a predetermined time unit to which an electronic signature and time stamp are added. To solve the above problems.

Here, means for snapshotting a hash value of data in time units before the time unit together with the data in time units, and means for sending the snapshot to a time stamp server, wherein the time stamp is You can get an attached snapshot.

The present invention also solves the above problems by a computer program for causing a computer to execute the above data management and storage method.

The present invention also solves the above problems by a computer program for causing a computer to function as the data management storage device.

According to the present invention, the use of time stamps ensures public proof of existence of data from the XAdES file . Furthermore, by chaining, it is possible to secure proof of completeness without omission in a series of data.

A diagram for explaining the problem of the data management and storage method proposed by the applicant in Patent Document 3. 1 is a block diagram showing the overall configuration of an enterprise backbone system into which a data management and storage method of an embodiment to which the present invention is applied is introduced; FIG. Block diagram showing the overall hardware configuration of the enterprise backbone system A block diagram showing a hardware configuration of a computer device used in the enterprise backbone system. Flowchart showing core business in the embodiment FIG. 2 is a block diagram showing the configuration of the data management storage device used in the embodiment; Flowchart showing data management and storage work processing in the embodiment Flowchart showing data management and storage processing in the embodiment Data structure diagram showing the relationship between the snapshot acquisition information (CSV format file) and the block unit generation file in the above embodiment. FIG. 2 is a data configuration diagram showing the configuration of a block unit generation file in the embodiment; Data configuration diagram showing a block unit generation file generated at regular dates and times in the embodiment. Flowchart showing processing of the first embodiment to which the present invention is applied Data configuration diagram showing an example of information to be processed by the above embodiment Flowchart showing processing of the second embodiment to which the present invention is applied Data configuration diagram showing another example of information to be processed by the above embodiment Explanatory drawing showing a comparative example of the present invention Explanatory diagram showing the basic configuration of the reference form Flow chart showing the same processing procedure A diagram showing the basic configuration of an embodiment of the present invention Flow chart showing the same processing procedure Similarly, a diagram explaining the XAdES timestamp

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In addition, the present invention is not limited by the contents described in the following embodiments and examples. In addition, the configuration requirements in the embodiments and examples described below include those that can be easily assumed by those skilled in the art, those that are substantially the same, and those that fall within the so-called equivalent range. Furthermore, the constituent elements disclosed in the embodiments and examples described below may be combined as appropriate, or may be selected and used as appropriate.

FIG. 2 is a block diagram showing the overall configuration of an enterprise backbone system into which the data management and storage method of the embodiment to which the present invention is applied is introduced.

In FIG. 2, a purchase management server device 50, an inventory management server device 51, a sales management server device 52, and an accounting management server device 56 are provided in each of the company's purchasing department, material department, sales management department, and accounting department. there is These purchase management server device 50, inventory management server device 51, sales management server device 52, and accounting management server device 56 are all constructed by a distributed DB (Data Base) application system, and an ERP system is applied as a whole. It is

Expense information generated in the purchase management server device 50, the inventory management server device 51, and the sales management server device 52 can be exchanged in a general-purpose format such as CSV (Comma Separated Values) or XML (Extensible Markup Language), or in a dedicated format. Accordingly, the information is appropriately aggregated in the accounting management server device 56, and a so-called journal or general ledger is created by the integration, and these are utilized as accounting information.

The data management/storage device 10 of this embodiment is installed in such a corporate backbone system. The purchase management server device 50, the inventory management server device 51, the sales management server device 52, and the accounting management server device 56 are devices to be managed by the data management storage device 10 of this embodiment to which the present invention is applied. . These devices are hereinafter referred to as managed DB devices. These managed DB devices have managed databases in which data generated in time series are stored in table format files (hereinafter referred to as original files).

In addition, the data management storage device 10 applies the present invention to periodically snapshot the information of these original files as information in a predetermined file format such as CSV format or XML format (hereinafter referred to as snapshot acquisition information). Get and save. As a result, at a later date, the table information at the time when the snapshot was taken can be made available for viewing. Note that in FIG. 2, the process of acquiring such snapshot acquisition information is indicated by the dashed-dotted arrow.

Here, the above snapshot acquisition information may be in the same file format as the original file. Alternatively, the information of the original file may be obtained directly as binary data. Furthermore, the substantial contents of the information of the original file may be once converted into CSV format, XML format, other general-purpose format, or dedicated format.

FIG. 3 is a block diagram showing the overall hardware configuration of the enterprise backbone system of this embodiment.

As shown in FIG. 3, the enterprise core system targeted by the present embodiment shown in FIG. 2 described above includes a purchase management server device 50, an inventory management server device 51, a sales management server device 52, and an accounting management server. The device 56 and also the data management and storage device 10 are interconnected by the network 1 . Additionally, a client device 5 connecting to these devices is also connected by the network 1 . Through this connection, file exchange in a general-purpose format or a dedicated format as described above is performed.

Note that the network 1 is not particularly limited. It may be one that uses a public line or a dedicated line, one that uses the Internet, a WAN (Wide Area Network), a LAN (Local Area Network), or one that is configured by connecting these in a complex manner.

FIG. 4 is a block diagram showing the hardware configuration of a computer device used for each device of this embodiment.

In FIG. 4, a kind of computer that can be used as each device of the purchase management server device 50, the inventory management server device 51, the sales management server device 52, the accounting management server device 56, and the data management storage device 10 The hardware configuration of the device is shown. However, each device is not limited to such.

The computer device shown in FIG. 4 may be a general PC (Personal Computer) device having Windows (registered trademark) of Microsoft Corporation installed as an OS (Operating System) as an example, and is not particularly limited. Alternatively, hardware other than a PC device may be used, for example, hardware such as a so-called work station such as an EWS (Engineering Work Station) may be used. It should be noted that in FIG. 4, the hardware configuration is partially abstracted for the sake of explanation.

4, the computer device includes a CPU (Central Processing Unit) 310, a RAM (Random Access Memory) 311, a ROM (Read Only Memory) 312, a LAN-I/F (Interface) 313, and a MODEM ( modulator-demodulator) 314 and various I/Fs 320-322. These are interconnected by bus 301 .

Note that the LAN-I/F 313 is used for connecting to the network 1 .

A screen display device 330 is also connected to the bus 301 via an I/F 320 . A keyboard 331 , a mouse 332 , and a printer device 333 interconnected by the bus 303 are connected to the bus 301 via an I/F 321 .

Furthermore, an HDD (Hard Disk Drive) device 340 and a CD (Compact Disc) drive device 341 are connected to the bus 301 via an I/F 322 . These are interconnected by bus 302 .

In the above hardware configuration, storage means and storage devices are RAM 311, ROM 312, HDD device 340, CD drive device 341, and the like. Various programs executed by the CPU 310, databases, various files, and data accessed in this embodiment are stored in such storage means and storage devices, and can be accessed electronically. For example, an OS, a program for providing an environment that uses software resources such as a database, JAVA (registered trademark), and JSP (Java (registered trademark) Server Page), an application program according to the present embodiment, and a web browser. The browser program is stored in HDD device 340 and is read into RAM 311 and executed by CPU 310 when executed. The application programs executed by the CPU 310 include JAVA (registered trademark) applets obtained via the network 1 and those provided by the ASP (Active Server Pages) function of the data management storage device 10. included.

When executing the OS, application programs, etc., the operator refers to the information displayed on the screen display device 330 and performs character input and various operations using the keyboard 331 and coordinate input and various operations using the mouse 332 . input. For example, the mouse 332 can be used to select an electronic document displayed in a list, specify a range such as a search in an electronic document being browsed, and perform various operations such as a click operation or a so-called drag-and-drop operation. perform operations. In addition, necessary information can be printed out from the printer device 333 as appropriate. Needless to say, these various outputs and inputs are electronically processed by a program executed by the CPU 310 .

The CD drive device 341 is used for installation of application programs and other off-line information exchange when the present invention is applied and implemented.

FIG. 5 is a flow chart showing core business in this embodiment.

In this flow chart, step S1000 is the operation of the purchase management server device 50, the inventory management server device 51, the sales management server device 52, and the accounting management server device 56 in the purchasing department, materials department, sales management department, accounting department, etc. Another system operation is shown. These devices constitute a distributed DB, and can exchange information with each other via the network 1 as necessary.

Next, step S1020 is an integrated system in which the purchasing management server device 50, the inventory management server device 51, the sales management server device 52, and the accounting management server device 56 are linked in the enterprise core system of this embodiment. Show operations. In particular, in this enterprise core system, miscellaneous expense information generated by the purchase management server device 50, the inventory management server device 51, and the sales management server device 52 is appropriately aggregated in the accounting management server device 56, and in the accounting management server device 56 We create journals and general ledgers and use them as accounting information.

Furthermore, in step S1040, the present invention is applied to perform data management and storage work processing using snapshots. This enables viewing of tax audits and other long-term storage information.

Here, the system operations of steps S1000, S1020 and S1040 are conceptually established in this order, but in practice they are always operated in parallel. FIG. 5 merely shows the concept of such system operation.

FIG. 6 is a block diagram showing the configuration of the data management storage device used in this embodiment.

FIG. 6 shows the configuration of the data management/storage device 10 shown in FIGS. 2 and 3 above. As shown in FIG. 6, the data management storage device 10 includes a snapshot processing unit 22, a blocking processing unit 24, a block compression/encryption processing unit 26, and an index data table creation processing unit 28. , a data management and storage processing unit 30 , a block-by-block decoding processing unit 32 , a browsing processing unit 34 , and a block search processing unit 36 . Further, the data management/storage device 10 includes a data storage device 40 that stores the information saved by the data management/storage processor 30 described above.

First, the snapshot processing unit 22 targets the original files stored in each device of the managed DB device (managed server device) 12 and acquires the snapshot acquisition information as described above. This snapshot acquisition is performed manually or automatically periodically, and the information of the original file at that time can be acquired as the snapshot acquisition information.

The blocking processing unit 24 generates a file (hereinafter referred to as a block unit generation file) in which the acquired snapshot acquisition information is organized into blocks for each predetermined number of records. The number of records included in each block is approximately equal to or greater than the number of records that are expected to be included in the browsing unit when browsing later. For this reason, the browsing can usually be handled by accessing one block, and by suppressing the number of blocks to be processed, the browsing can be efficiently performed.

Next, the block-by-block compression/encryption processing unit 26 compresses/encrypts the block-based generation file organized in this manner in units of blocks of the organization. Also, the index data table creation processing unit 28 creates an index data table in which at least record sequence information obtained by sorting the records included in the block unit generation file by specific data is stored for each block unit generation file. do.

The data management/storage processing unit 30 stores the block unit generated file compressed and encrypted in block units and the above index data table in the data storage device 40 . Further, the data management/storage processing section 30 performs a process of reading out a desired block-by-block generation file stored in this way. An HDD device, an MT device, or the like is used for the data storage device 40 .

Next, the block-by-block decoding processing unit 32 browses the block-unit generated file, and when browsing the original file, decompresses and decompresses the block-unit generated file in units of blocks that organize the block-unit generated file. Decrypt.

When using the index data table to search for a record in the table stored in the data management and storage database, the block search processing unit 36 first predicts which block in the block unit generation file the target record is stored in, The predicted block is compressed, decompressed after encryption, and decoded to search for the block. As a result, the retrieval result is obtained while partially decompressing and decoding the table to be retrieved. Therefore, the compression/encryption decompression/decryption processing can be limited to the minimum necessary blocks, and the processing speed at the time of search and browsing can be improved.

Subsequently, the browsing processing unit 34 receives a usage request from the user from the client device 5 . Also, the browsing processing unit 34 provides the search result for browsing by the user.

Here, an instruction for browsing target information and a search instruction are input from the user to the browsing processing unit 34 via the client device 5 . The browse processing unit 34 transmits this input content to the block search processing unit 36 . The block search processing unit 36 instructs the block-by-block decoding processing unit 32 to decompress/decode the compression/encryption based on the input content and the corresponding index data table stored in the data storage device 40. A block-based generated file and a block in the block-based generated file to be processed are indicated.

Then, the block-by-block decryption processing unit 32 reads the blocks of the instructed block unit generation file from the data storage device 40 by the data management and storage processing unit 30, decompresses and decodes the blocks, and sends them to the viewing processing unit 34. Output. Thereafter, the browsing processing unit 34 browses the client device 5 based on the decompressed/decrypted block unit generated file.

FIG. 7 is a flow chart showing data management and storage work processing in this embodiment.

This flow chart shows the data management and storage task processing in step S1040 of FIG. 5 described above.

In FIG. 7, first, in step S1100, various settings related to this data management and storage task processing are made. This data management and storage task processing can start taking a snapshot to which the present invention is applied either manually or automatically at a regular date and time. In step S1100, various settings such as manual or automatic setting and setting of regular date and time in the case of automatic setting are performed.

Next, in step S1120, data management and storage processing is performed to acquire snapshots, store information, and so on to which the present invention is applied.

In each device of the managed DB device 12, various information is generated in time series, and such information is stored in a table format file (original file). In this step S1120, the data management storage device 10 periodically acquires a snapshot of the information of these original files as snapshot acquisition information in a predetermined format, and converts the file into blocks by applying the present invention as will be described later. Save by (block unit generated file). In this embodiment, a snapshot is taken at a business stationary point of each managed DB device 12, which is a host system.

It should be noted that this block unit generation file is compressed and encrypted in block units. Therefore, the block unit generation file can be easily stored in large quantities and for a long period of time. Furthermore, while enabling high-speed access and high-speed search, it is possible to prevent data falsification and ensure security by means of encryption.

Here, it is possible to some extent to prevent data tampering and to ensure security by management based on the privileges of the OS. However, there is a limitation that a privileged user can tamper with it. In this embodiment, in addition to compression and encryption, data tampering prevention and security are ensured by management based on OS privileges.

It should be noted that as the frequency of appearance of similar information increases, the compression rate in compression processing improves. In the block-based generated file of this embodiment, the possibility of appearance of similar information increases in block units. Therefore, in this embodiment, there is a high possibility that the compression ratio will be improved. For example, the compression ratio can be improved compared to compression/encryption in units of records.

In FIG. 7, subsequently in step S1140, the information saved in step S1120 as described above can be provided for viewing at a later date as information of the corresponding original file at the time the snapshot was taken. For example, at the time of a tax audit, the information is displayed on the screen, printed out, or output as a file output converted into a predetermined file format such as CSV format or XML format for viewing by tax officials. In this browsing, a function of searching and extracting necessary information is provided.

FIG. 8 is a flowchart showing data management and saving processing in this embodiment.

This flowchart shows the contents of the data management and saving process of step S1120 in the flowchart of FIG. 7 described above.

In this flowchart, first, in step S1300, the snapshot processing unit 22 acquires the information of the original file of each device of the managed DB device 12 as snapshot acquisition information.

In step S1320, the blocking processing unit 24 performs blocking processing for organizing the snapshot acquisition information into blocks of a predetermined number of records.

In step S1340, the block-by-block compression/encryption processing unit 26 performs compression/encryption processing for compressing/encrypting the snapshot-obtained table data organized in blocks in this way in block units.

Furthermore, in step S1360, the index data table creation processing unit 28 saves at least record sequence information obtained by sorting the records included in the table by a specific data item for each table at the time of the snapshot. Create index data table creation process.

In step S1380, data management storage processing is performed to store the information compressed and encrypted in step S1340 described above and the index data table created in step S1360 described above in data storage device 40 in data management storage processing section 30. .

FIG. 9 is a data configuration diagram showing the relationship between the snapshot acquisition information (CSV format file) and the block unit generation file in this embodiment. FIG. 10 is a data configuration diagram showing the configuration of the block unit generation file.

The snapshot processing unit 22 of this embodiment acquires, as snapshot acquisition information, the original file of the data generated in time series, which is stored in table format in each device of the managed DB device 12 described above. . The file format of the snapshot acquisition information is not particularly limited, but may be converted into a CSV format file as shown in FIG.

In this embodiment, the snapshot acquisition information is organized into a plurality of blocks, each block consisting of M records, thereby generating a block unit generation file. The number of records M is approximately equal to or larger than the number of records expected to be included in the browsing unit when browsing later. For this reason, the browsing can usually be handled by accessing one block, and by suppressing the number of blocks to be processed, the browsing can be efficiently performed.

Also, as shown in FIG. 10, this block-based generation file has a file header at the top and a file footer at the end, and information organized by block of snapshot acquisition information is incorporated between these.

Here, if the snapshot acquisition information of the file in CSV format has K records, N is the integer value of (K/M) plus one. Also, as shown in the figure, this final block N contains the final record in the original information of the file in CSV format.

Also, as shown in FIGS. 9 and 10, each block has a block header at the head and a block footer at the tail. Management information is stored in these block headers and block footers, and by means of these block headers and block footers, consecutive blocks are chained in sequence in the block unit generated file. The block header stores the address of the previous block in the block unit generated file, and the block footer stores the address of the next block in the block unit generated file.

Here, in these FIGS. 9 and 10, each record is information of one employee. Each record contains the name of the office to which the employee belongs, such as "Tokyo", the name of the department to which the employee belongs, such as "accounting" or "sales", the name of the employee such as "Makoto Abe" or "Takashi Kimura", It includes employee address information such as "Chiba Prefecture...".

FIG. 11 is a data configuration diagram showing a block unit generation file generated at regular dates and times in this embodiment.

In this embodiment, acquisition of information by snapshots is performed in chronological order. In addition, it is possible to set a specific date and time of every month, or a specific month and date and time for accounting purposes, as a regular date and time, and automatically acquire information by snapshot.

FIG. 11 shows an example of automatically acquiring information by snapshot at a specific date and time (regular date and time) every month. When the information is acquired, the snapshot acquisition information of the CSV format file of the original file at the date and time of the acquisition is acquired every month. Further, in this manner, a block unit generation file is generated each month according to the acquired file, which is blocked according to the present invention.

Here, in the present embodiment, snapshot acquisition information newly acquired on a monthly basis is combined with the past block-based generation file at a preset periodic date and time to obtain the latest snapshot acquisition information at this time. to generate compressed and encrypted block unit generation files. The combined, compressed, and encrypted block unit generated file is stored in the data storage device 40 through processing by the data management and storage processing unit 30 .

To generate such a combined block unit generated file, for example, after once decrypting the past block unit generated file, new snapshot acquisition information (without compression/encryption) is combined with this, It may be performed by compressing and encrypting the synthesized data. Alternatively, after first compressing and encrypting the new snapshot acquisition information, the compressed and encrypted past block unit generation file may be synthesized as it is without being decrypted. .

It should be noted that such synthesis may not be performed, and a new compressed/encrypted block unit generation file may be generated each time at a preset periodic date and time. However, in the synthesis as described above, the processing amount of compression/encryption can be suppressed, and the processing speed can be improved.

As described above, the processing units and the data storage device 40 in the data management and storage device 10 shown in FIG. 6 are configured in the data management and storage device 10 in FIGS. However, this embodiment is not limited to such. For example, the accounting management server device 56 shown in FIGS. and the data storage device 40 may be configured. When the data management storage device 10 is configured in a complex manner in the accounting management server device 56 , the data storage device 40 may be provided in the database device or storage device provided in the accounting management server device 56 .

FIG. 12 is a flow chart showing processing of the first embodiment to which the present invention is applied .

In the present embodiment, the managed DB device 12 in the embodiment described above is the accounting management server device 56, which is a database storing at least accounting information. In addition, the above-mentioned regular dates and times are daily and monthly dates and times when information is fixed for accounting purposes.

This flow chart corresponds to the entire flow chart of FIG. 5 described above. Also, the "data management and storage task processing", which is step S1040 in the flowchart of FIG. 5, is as shown in the entire flowchart of FIG. Therefore, the flowchart of FIG. 12 of this embodiment incorporates the entire flowchart of FIG. 7 into step S1040 of FIG.

Furthermore, as shown in FIG. 12, the "data management and saving process" in step S1120 is performed by the "daily snapshot process" in step S2100 and the "monthly information synthesizing process" in step S2120. It is configured. Also, the setting of the first periodic date and time and the second periodic date and time, which will be described below in this embodiment, can be performed in the task setting process in step S1100 described above. Note that the first regular date and time may be daily, and the second regular date and time may be monthly, but they are not limited to these. For example, the second periodic date and time may be a quarterly or yearly closing cycle, which is longer than the first periodic date and time.

In the "daily snapshot processing" of step S2100, a snapshot of the information of the database is acquired daily (first periodic date and time), and the acquired information is generated in units of blocks by organizing the blocks as described above. A file is generated, and the block unit generated file is compressed/encrypted and stored in the data storage device 40 (data management/storage database).

In this step S2100, processing from snapshot acquisition to at least block organization is performed. For example, the compression/encryption may be omitted, and the block unit generation file processed up to the block organization may be stored in the data storage device 40 (data management storage database). However, by performing compression and encryption, it is possible to further reduce the storage capacity required for the data storage device 40 and to further improve security.

Further, in the "monthly information synthesizing process" in step S2120, the blocks are extracted from the plurality of block-based generation files stored daily on a monthly basis (second periodic date and time). Synthesize unit generation files.

This file composition of the present embodiment is not specifically limited, and the composition processing of the block unit generation file and the creation processing of the index data table which are performed in the file composition are not specifically limited. For example, only one of the block unit generation file synthesis process and the index data table creation process may be performed in the file synthesis.

In addition, regarding the synthesizing process of the block unit generated file at the time of the file synthesis, for example, once the multiple block unit generated files of the past target period obtained on a daily basis are once decoded, they are synthesized and synthesized. It may be performed by compressing and encrypting the data. Alternatively, a plurality of block unit generated files for these target periods may be synthesized without being decoded.

Creation of the index data table at the time of file synthesis is not specifically limited either. For this index data table creation process, the index data tables created when multiple block unit generation files for the past target period were generated are synthesized on a daily basis, thereby creating a monthly unit index data table. You may Alternatively, when synthesizing the block unit generation file on a monthly basis, a new monthly unit index data table may be created at the same time.

Here, FIG. 13 is a data configuration diagram showing an example of information to be processed in this embodiment.

In step S1000 of FIG. 12 and step S1000 of FIG. 5 described above, various information is generated in each corresponding work by the purchase management server device 50, the inventory management server device 51, and the sales management server device 52. . In step S1020, the accounting management server device 56 collects, as appropriate, the accounting management server device 56, and the accounting management server device 56 prepares journals, general ledger, and the like. be done. In FIG. 13 and FIG. 15 described later, the information acquired or created by the accounting management server device 56 is collectively referred to as detailed accounting information.

In FIG. 13, the detailed accounting information A1 to A3 are "2011/5/1", the detailed accounting information B1 to B3 are "2011/5/30", and the detailed accounting information C1 to C3 are "2011/5/31". Secondly, it is the information created by collecting the information from the purchase management server device 50, the inventory management server device 51, the sales management server device 52 and the like in the accounting management server device 56 as appropriate.

Subsequently, in step S1100, various settings such as manual or automatic setting of the periodic date and time, setting of the first periodic date and second periodic date and time in the case of automatic setting, and the like are appropriately performed. In the present embodiment, the setting is "automatic", and regarding the periodic date and time, the date and time setting of the "daily snapshot processing" (time setting for each day (first periodic date and time setting)) and processing content , month and time setting (monthly date and time setting (second periodical date and time setting)) and processing contents of the "monthly information synthesizing process".

Next, in the "daily snapshot processing" of step S2100 in step S1120, as indicated by arrows D1 to D3 in FIG. ) is generated and stored in the data storage device 40 . The generation is performed on a daily basis (first regular date and time), obtaining a snapshot of the detailed accounting information in the accounting management server device 56, and dividing the acquired information into blocks to organize the daily accounting information. (block unit generation file), and compression/encryption of the daily accounting information.

Subsequently, in the "monthly information synthesizing process" of step S2120 in step S1120, as indicated by the arrow F1 in FIG. Synthesize monthly accounting information (block-based generation file) from the daily accounting information that is generated. In the example of FIG. 13, the monthly accounting information for May 2011 is synthesized and generated, and this synthesizing and generating process is performed on June 1, 2011, the next month, for example.

In this embodiment, the information (daily accounting information) acquired by compressing and encrypting while acquiring snapshots is for each date, but at the beginning of each month, the previous month's information is synthesized into the monthly accounting information. , the number of target files will be reduced when searching at a later date. Therefore, the processing amount of search processing is reduced, and the processing efficiency is improved.

Here, this embodiment assumes a case where the accounting information is finalized on a daily basis.

Next, FIG. 14 is a flow chart showing the processing of the second embodiment to which the present invention is applied .

In the present embodiment, the "data management and saving processing" of step S1120 of the first embodiment described above is configured by the "monthly snapshot processing" of step S2200. Not performed.

In this embodiment, the regular date and time mentioned above is a monthly date and time when the information is fixed in terms of accounting work. In step S1100, in this embodiment, "automatic" is set, and the date and time of "monthly snapshot processing" (monthly date and time setting (regular date and time setting)) and processing contents are set as appropriate.

Here, FIG. 15 is a data configuration diagram showing an example of information to be processed in this embodiment.

In FIG. 15, the detailed accounting information K1 to K3 are "2011/5/1", the detailed accounting information L1 to L3 are "2011/5/31", and the detailed accounting information M1 to M3 are "2011/6/1". Further, the detailed accounting information N1 to N3 are collected by the accounting management server device 56 from the purchase management server device 50, the inventory management server device 51, the sales management server device 52, etc. on "June 30, 2011" and created. information.

In the "monthly snapshot processing" of step S2200 in FIG. 14 of this embodiment, as indicated by arrows P1 and P2 in FIG. ) is generated and stored in the data storage device 40 . The generation is performed on a monthly (regular date and time) basis, and a snapshot of the detailed accounting information in the accounting management server device 56 is acquired, and monthly accounting information (block units) is organized by dividing the acquired information into blocks. generated file), and compression/encryption of the monthly accounting information.

As described above, in this embodiment, block unit generation files are not combined, and a new compressed/encrypted block unit generation file is generated each time in the "monthly snapshot processing" of step S2200. I have to. By comparing with the present embodiment, it can be seen that the above-described first embodiment, in which the synthesis process is performed, can suppress the amount of compression/encryption processing as a whole, and can improve the processing speed. .

According to this technique, data having a basic configuration as shown in FIG. 1 can be obtained. With this technology, each snapshot was encrypted, and although there was no logic for data modification, there was no public proof of data existence. Also, for example, the snapshot 62N on day N and the snapshot 62N+1 on day N+1 are not chained, and even if they were deleted, it could not be proven.

Here, as shown in FIG. 16, it is conceivable to give a time stamp 66 to each snapshot 62N, 62N+1, 62N+2, . . . This ensures public proof of existence. However, the snapshots are not chained, and the deletion of transaction data 60 cannot be detected.

Therefore, in the reference embodiment, as shown in FIG. 17, the transaction data 60 within the predetermined unit period (here, N days of the current day) is added to the hash value of the time unit (here, N-1 days of the previous day) before the time unit. By adding 64N-1 and adding a timestamp 66, the timestamp 66 proves public existence, and the snapshot is also chained to prove that the transaction data 60 has not been deleted (integrity). It was made possible.

The processing procedure of the reference embodiment will be described below with reference to FIG. 18 .

First, in step S1400, the hash value (64N-1 in FIG. 17) of the transaction data 60 of the previous day (N-1 days) is calculated.

Next, in step S1410, the hash value 64N-1 of the transaction data 60 of the previous day (N-1 days) is converted into a snapshot 62N together with the transaction data 60 of the current day (Nth day).

Next, in step S1420, snapshot 62N is sent to an external time stamp server (not shown) connected to the Internet, for example, to obtain time stamp 66. FIG.

The process then advances to step S1430 to obtain snapshot 62N with timestamp 66 appended.

In this way, not only is the timestamp 66 ensuring proof of public existence, but the snapshots 62N, 62N+1, 62N+2, . be done.

Next, an embodiment of the present invention using an XAdES file (JIS X5093:2008) will be described.

In this embodiment , as shown in the basic configuration of FIG. 19, a hash value 64N of a snapshot 62N containing transaction data 60 of a plurality of continuous time units (here, N days of the current day), and , and the hash value 64N-1 of the snapshot of the time unit before the predetermined time unit (here, the previous day N - 1). Along with proving its existence, the snapshot 62N is chained to detect the deletion of the transaction data 60 so that its integrity is ensured.

FIG. 20 shows the processing procedure of this embodiment.

First, in step S1500, snapshots 62N-1 and 62N are generated from the transaction data 60 of the previous day (N-1 days) and the current day (N days).

Then, in step S1510, the hash values 64N-1 and 64N are calculated respectively.

Next, in step S1520, an XML-format Manifest file 74 as illustrated in FIG. 21 is created.

Next, in step S1530, the Manifest file 74 is sent to the time stamp server 76, the XAdES file 74 with the electronic signature 78 and the time stamp 72 returned from the time stamp server 76 is obtained, and data is managed together with the original file 80. Store in the storage device 10 . As a result, the public existence proof and integrity of the original file 80 can be verified based on the XAdES file 70N.

In the above embodiment, the time unit is date and time or monthly, but the time unit is not limited to this. The target of storage is not limited to accounting information.

DESCRIPTION OF SYMBOLS 1... Network 5... Client apparatus 10... Data management storage apparatus 12... Managed database apparatus (managed server apparatus)
22 Snapshot processing unit 24 Blocking processing unit 26 Compression/encryption processing unit by block 28 Index data table creation processing unit 30 Data management storage processing unit 32 Decryption processing unit by block 34 Browsing processing unit 36 Block search processing unit 40 Data storage device 50 Purchasing management server device 51 Inventory management server device 52 Sales management server device 56 Accounting management server device 60 Transaction data 62N, 62N+1, 62N+2 Snapshot 64N-1 , 64N, 64N+1, 64N+2... Hash values 66, 72... Timestamps 70N, 70N+1, 70N+2... XAdES files 74... Manifest files 76... Timestamp servers 78... Electronic signatures 80... Original files

Claims (4)

In a data management and storage method for periodically storing information in a managed database in which hourly data occurring in chronological order is stored in a snapshot,
snapshot the current time unit data and the time unit data before the current time unit,
creating a Manifest file containing hash values of the snapshots of the consecutive time units of data;
Send the Manifest file to the timestamp server,
A data management and storage method, characterized by obtaining an XAdES file of a predetermined time unit to which an electronic signature and a time stamp are added by the time stamp server . A data management storage device that periodically snapshots and stores information in a managed database in which hourly data generated in chronological order is sequentially stored,
means for snapshotting the current time unit data and the time unit data before the current time unit;
means for creating a Manifest file containing hash values of snapshots of the successive time units of data;
means for sending the Manifest file to a timestamp server;
A data management and storage device , wherein an XAdES file of a predetermined time unit to which an electronic signature and a time stamp are added by the time stamp server is obtained . A computer program for causing a computer to execute the data management and storage method according to claim 1 . A computer program for causing a computer to function as the data management storage device according to claim 2 .

Images