JP2020204978A - Data managing and storing method, data managing and storing device and computer program for implementing these - Google Patents

Abstract

To ensure proof of public existence of data and to ensure proof of integrity in which a sequence of pieces of data is not missing.SOLUTION: A data managing and storing method that manually or automatically and periodically takes snapshots 62N, 62N+1, 62N+2, ... of information of a management target database, in which time series generated data is stored, to store, calculates a hash value 64N-1 of transaction data 60 of a time unit (N-1 day) before at least a predetermined time unit (N day), and adds a time-stamp 66 to the hash value 64N-1 of the transaction data 60 of the time unit (N-1 day) before the time unit (N day) and the transaction data 60 of the time unit (N day) to chain among snapshots 62N, 62N+1, 62N+2,....SELECTED DRAWING: Figure 17

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 methods and the data management and storage device, and in particular, while ensuring public existence proof of data. It relates to a data management storage method and a data management storage device capable of ensuring completeness, and a computer program for implementing the data management storage method and the data management storage device.

As an accounting system, migration to ERP (Enterprise Resource Planning) system represented by SAP, migration from main frame to distributed system (downsizing) is seen, and many distributed DB (Data Base) application systems are also adopted. Has been done. Initially, with the transition to the ERP system, it seemed possible to store transaction details, etc. stipulated by tax law for a long period of time.

However, as the amount of information to be stored increases, the information storage resource will be squeezed, and the past amount will be saved in MT (Magnetic Tape) or the like. Accounting information is required to be stored for 7 years under tax law, but most companies can only access information for 1 to 2 years online, and information before this will be stored offline for MT and others. Therefore, the national tax examiner asks the information that is not on the online system to output the necessary data from the offline one in a batch, and imports this into database management software such as Microsoft ACCESS for auditing. There is.

In addition, for important information such as accounting information, it is necessary to take sufficient measures against falsification and leakage of information, and if the information is stored in large quantities for a long period of time, the damage may be enormous, so even more thorough measures should be taken. Need to take. Therefore, it is necessary to enable high-speed access and high-speed search, and at the same time, sufficiently prevent data tampering by encryption and ensure security.

Here, in Patent Document 1, a snapshot backup image that allows a user to have unlimited access to the system even during the backup process and does not require reconstruction can be quickly and consistently backed up on the MT. The technology that enables the creation of a patent is disclosed.

Further, in Patent Document 2, although it is a snapshot management method using difference information with good disk usage efficiency, there is no deterioration in writing performance, and a snapshot having a restoration function that minimizes operation stop time and operation restart time. A functional snapshot management system is disclosed.

However, Patent Document 1 and Patent Document 2 do not consider the characteristics of accounting information as described above, and while enabling long-term storage of important large amounts of information and high-speed access and high-speed retrieval thereof, at the same time. There is no disclosure about how to prevent data tampering by encryption and ensure sufficient security.

The applicant has proposed Patent Document 3 as a solution to such a problem. 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 period of time, enable high-speed access and high-speed search, and further tamper with data by encryption. It can prevent and ensure security.

By the technique of Patent Document 3, data having a basic configuration as shown in FIG. 1 can be obtained. In the figure, 60 is each transaction data, and 62N, 62N + 1, 62N + 2 ... Are snapshots of predetermined time units, for example, daily units or monthly units (daily units in the figure).

Special Table 2001-520779 Japanese Unexamined Patent Publication No. 2010-79331 Japanese Patent No. 5844554

However, it was not possible to secure the proof of public existence of the data or to detect the deletion of the data to secure the proof of integrity. That is, in the technique proposed in Patent Document 3, each snapshot is compressed / encrypted in block units, and although there is no logic for changing data, there is no official proof of existence of data. Also, for example, the snapshot 62N on day N and the snapshot 62N + 1 on day N + 1 were not chained, and it could not be proved that they were not deleted.

The present invention has been made to solve the above-mentioned conventional problems, and an object of the present invention is to secure a proof of public existence of data and a proof of completeness of a series of data without omission.

The present invention is a data management saving method in which information of a managed database in which data generated in a time series is stored is manually or automatically periodically converted into a snapshot and saved, at least in the predetermined time unit. To chain the snapshots by calculating the hash value of the data in the earlier time unit and adding a time stamp to the hash value of the data in the time unit before the time unit and the data in the time unit. To solve the above-mentioned problems.

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

Further, the data of the time unit and the data of a plurality of consecutive time units including the data of the time unit before the time unit are snapshotted, and the hash value of the data of the plurality of consecutive time units is obtained. Manifest file is created and the Manifest file is sent to a time stamp server to obtain an XAdES file in a predetermined time unit with an electronic signature and a time stamp.

The present invention also relates to a data management storage device that manually or automatically periodically periodically snapshots and stores information in a database to be managed in which data generated in time series is stored. It is provided with a means for calculating the hash value of the data in the time unit before the time unit, and a means for adding a time stamp to the hash value of the data in the time unit before the time unit and the data in the time unit. A data management and storage device characterized in that snapshots are chained together similarly solves the above problem.

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

Further, a means for taking a snapshot of the data of the time unit and the data of a plurality of consecutive time units including the data of the time unit before the time unit, and the data of the plurality of continuous time units. A means for creating a Manifest file of the hash value of the above and a means for sending the Manifest file to a time stamp server are provided, and an XAdES file in a predetermined time unit to which an electronic signature and a time stamp are added can be obtained.

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

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

According to the present invention, the public existence proof of data can be ensured by using the time stamp. Furthermore, by chaining, it is possible to ensure the proof of completeness of a series of data without any omission.

The figure for demonstrating the problem of the data management storage method proposed by the applicant in Patent Document 3. A block diagram showing the overall configuration of a corporate core system into which the data management and storage method of the embodiment to which the present invention is applied is introduced. A block diagram showing the overall hardware configuration of the corporate core system A block diagram showing a hardware configuration of a computer device used in the corporate core system. Flow chart showing core business in the above embodiment A block diagram showing a configuration of a data management storage device used in the above embodiment. Flow chart showing data management storage business processing in the above embodiment A flowchart showing the data management storage process 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. Data structure diagram showing the structure of the block unit generation file in the above embodiment Data structure diagram showing a block unit generation file generated at a periodic date and time in the above embodiment A flowchart showing the processing of the first embodiment to which the present invention is applied. Data structure diagram showing an example of information to be processed by the above embodiment A flowchart showing the processing of the second embodiment to which the present invention is applied. Data structure diagram showing other examples of information to be processed by the above embodiment Explanatory drawing which shows comparative example of this invention Explanatory drawing which shows the basic structure of 1st Embodiment of this invention Flow chart showing the processing procedure as well The figure which shows the basic structure of the 2nd Embodiment of this invention Flow chart showing the processing procedure as well Similarly, a diagram illustrating the XAdES time stamp.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The present invention is not limited to the contents described in the following embodiments and examples. In addition, the constituent 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, that is, those in a so-called equal range. Further, the components disclosed in the embodiments and examples described below may be appropriately combined or appropriately selected and used.

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

In FIG. 2, 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 provided in each of the purchasing department, the material department, the sales management department, and the accounting department of the company. There is. The 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 the ERP system is applied as a whole. Has been done.

Various cost information generated by the purchase management server device 50, the inventory management server device 51, and the sales management server device 52 is a file exchange in a general-purpose format such as CSV (Comma Separated Values) or XML (Extensible Markup Language) or a dedicated format. As a result, the accounting management server device 56 is appropriately aggregated and integrated to create a so-called journal, general ledger, and the like, which are utilized as accounting information.

In such a corporate core system, the data management storage device 10 of the present embodiment is introduced. 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 which the data management storage device 10 of the present embodiment is subject to management to which the present invention is applied. .. Hereinafter, these devices will be referred to as managed DB devices. These managed DB devices include a managed database in which data generated in time series is stored in a table format file (hereinafter referred to as an original file).

Further, the data management storage device 10 periodically snapshots the information of these original files in a predetermined file format information (hereinafter referred to as snapshot acquisition information) such as CSV format and XML format by applying the present invention. Get and save. As a result, the information on the table at the time of snapshot can be used for viewing at a later date. In FIG. 2, the arrow of the alternate long and short dash line indicates the process of acquiring such snapshot acquisition information.

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 directly acquired as binary data. Further, the actual content of the information in the original file may be once converted into a CSV format, an XML format or other general-purpose format, or a dedicated format.

FIG. 3 is a block diagram showing the overall hardware configuration of the enterprise core system of the present 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 the data management / storage device 10 are connected to each other by the network 1. In addition, the client device 5 connected to these devices is also connected by the network 1. By the connection, the above-mentioned general-purpose format or dedicated format file exchange is performed.

The network 1 is not particularly limited. It may use a public line or a dedicated line, use the Internet, WAN (Wide Area Network), LAN (Local Area Network), or connect and configure these in a complex manner.

FIG. 4 is a block diagram showing a hardware configuration of a computer device used for each device of the present 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 a device.

The computer device of FIG. 4 may be a general PC (Personal Computer) device equipped with Windows (registered trademark) of Microsoft Corporation as an example of the OS (Operating System), and is not particularly limited. Alternatively, hardware other than the PC device may be used, and hardware such as a so-called workstation such as EWS (Engineering Work Station) may be used. In FIG. 4, the hardware configuration is partially abstracted for the sake of explanation.

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

The LAN-I / F313 is used to connect to the network 1.

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

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

In the hardware configuration as described above, the storage means and the storage device are a RAM 311, a ROM 312, an HDD device 340, a CD drive device 341, and the like. In such a storage means or storage device, various programs executed by the CPU 310, a database, various files, and data accessed in the present embodiment are stored and can be accessed electronically. For example, a program for providing an environment for using an OS, a database, and software resources such as JAVA (registered trademark) and JSP (Java (registered trademark) Server Page), an application program according to the present embodiment, or a web. The browser program is stored in the HDD device 340, and at the time of execution, it is read into the RAM 311 and executed by the CPU 310. Note that some application programs executed by the CPU 310 are provided by a JAVA (registered trademark) applet acquired via the network 1 or an ASP (Active Server Pages) function in the data management storage device 10. included.

Further, when executing the OS, application program, or the like, the operator performs character input or various operations with the keyboard 331 or coordinates input or various operations with the mouse 332 while referring to the information displayed and output on the screen display device 330. And input. For example, the mouse 332 can be used to select an electronic document to be displayed in a list, to specify a range such as a search for an electronic document being viewed, or by 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 outputs and inputs are performed electronically by a program executed by the CPU 310.

The CD drive device 341 is used for installing an application program and exchanging information offline when the present invention is applied and implemented.

FIG. 5 is a flowchart showing the core business in the present embodiment.

In this flowchart, step S1000 is the business of 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 in the purchasing department, the material department, the sales management department, the accounting department, and the like. Indicates another system operation. Although these devices constitute a distributed DB, information can be exchanged with each other via the network 1 as needed.

Next, step S1020 is an integrated system in which 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 linked in the corporate core system of the present embodiment. Show operation. In particular, in the core system of the present company, various cost information generated by the purchase management server device 50, the inventory management server device 51, and the sales management server device 52 is appropriately collected in the accounting management server device 56, and the accounting management server device 56 is used. We create journals and general ledger and use them as accounting information.

Further, in step S1040, the present invention is applied to perform data management and storage business processing by snapshot. As a result, tax audits and other long-term storage information can be viewed.

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

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

FIG. 6 shows the configuration of the data management storage device 10 shown in FIGS. 2 and 3 described 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-specific compression / encryption processing unit 26, and an index data table creation processing unit 28. A data management / storage processing unit 30, a block-specific decryption processing unit 32, a browsing processing unit 34, and a block search processing unit 36 are provided. Further, the data management / storage device 10 includes a data storage device 40 that stores information stored by the data management / storage processing unit 30.

First, the snapshot processing unit 22 targets the original file 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 at regular intervals, 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 snapshot acquisition information acquired in this way is organized into blocks for each predetermined number of records. The number of records possessed by each block is set to be equal to or greater than the number of records predicted to be included in the browsing unit when browsing at a later date. Therefore, the browsing can usually be handled by accessing one block, and by suppressing the number of blocks to be processed, the browsing can be performed efficiently.

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

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

Next, when the block-based decoding processing unit 32 browses the block-based generated file and browses the original file, the block-based decryption processing unit 32 decompresses the block-based generated file in block units that organize the block-based generated file. Decrypt.

When the block search processing unit 36 uses the index data table to search for records in the table stored in the data management storage database, the block search processing unit 36 first predicts in which block the target record is stored in the block unit generation file. The block is searched by performing compression / encryption decompression / decryption of the predicted block. As a result, the search result is acquired while partially expanding / decoding the table to be searched. Therefore, the decompression / decryption processing of compression / encryption can be performed only on 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 the user's usage request from the client device 5. In addition, the browsing processing unit 34 makes the search result available for browsing by the user.

Here, the instruction of the information to be browsed and the instruction of the search are input from the user to the browsing processing unit 34 by the client device 5. The browsing processing unit 34 transmits this input content to the block search processing unit 36. The block search processing unit 36 decompresses / decrypts compression / encryption for the block-specific decryption processing unit 32 based on the input contents and the corresponding index data table stored in the data storage device 40. Instructs the block unit generation file to be processed and the blocks in the block unit generation file.

Then, the block-specific decoding processing unit 32 reads the block of the instructed block unit generation file from the data storage device 40 by the data management storage processing unit 30, and performs decompression / decoding processing to the viewing processing unit 34. Output. After that, the browsing processing unit 34 browses the client device 5 based on the block unit generation file that has been decompressed and decrypted.

FIG. 7 is a flowchart showing the data management storage business process in the present embodiment.

This flowchart shows the data management storage business process in step S1040 of FIG. 5 described above.

In FIG. 7, first, in step S1100, various settings related to this data management storage business process are performed. This data management and storage business process can be started manually or automatically at a periodic date and time for taking a snapshot to which the present invention is applied. In step S1100, various settings such as such manual or automatic setting and periodic date / time setting in the case of automatic setting are performed.

Next, in step S1120, a data management storage process for acquiring a snapshot, storing information, and the like to which the present invention is applied is performed.

Various information is generated in time series in each device of the managed DB device 12, and such information is stored in a table format file (original file). In step S1120, the data management / storage device 10 periodically acquires snapshots of the information of these original files as snapshot acquisition information in a predetermined format, and applies the present invention to the blocked file as described later. Save by (block unit generation file). In this embodiment, snapshots are taken at a stationary point in business of each of the managed DB devices 12 that are higher-level systems.

The 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 tampering by encryption and ensure security.

Here, it is possible to prevent data tampering and ensure security to some extent by managing with the privilege of the OS. However, there is a limit that a privileged user can tamper with it. In this embodiment, in addition to compression / encryption, data tampering is prevented and security is ensured by managing with the privilege of the OS.

As the frequency of appearance of similar information increases, the compression rate in the compression process improves. In the block unit generation file of this embodiment, there is a high possibility that similar information will appear in block units. Therefore, in this embodiment, there is a high possibility that the compression ratio will be improved. For example, the compression rate can be improved as compared with the compression / encryption of each record.

In FIG. 7, subsequently, in step S1140, the information saved in step S1120 as described above can be used for viewing at a later date as providing the information of the corresponding original file at the time of snapshot. For example, at the time of a tax audit, the screen display, print output, and file output converted into a predetermined file format such as CSV format or XML format are provided for viewing by tax officials. At the time of this browsing, it is equipped with a function to search and extract necessary information.

FIG. 8 is a flowchart showing the data management storage process in the present embodiment.

This flowchart shows the contents of the data management storage process in 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 the snapshot acquisition information.

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

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

Further, in step S1360, the index data table creation processing unit 28 stores at least the information of the record sequence in which the records included in the table are sorted by the specific data item for each table at the time of snapshot. Performs index data table creation processing to create.

In step S1380, the data management storage processing unit 30 stores the information compressed / encrypted in step S1340 and the index data table created in step S1360 in the data storage device 40. ..

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

The snapshot processing unit 22 of the present embodiment acquires, as snapshot acquisition information, the original file of data generated in time series, which is stored in a table format in each device of the above-mentioned managed DB device 12. .. 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. 9.

In the present embodiment, the information of the snapshot acquisition information is organized into a plurality of blocks in which each block is composed of M records, whereby a block unit generation file is generated. The number of records M is set to be equal to or greater than the number of records predicted to be included in the browsing unit when browsing at a later date. Therefore, the browsing can usually be handled by accessing one block, and by suppressing the number of blocks to be processed, the browsing can be performed efficiently.

Further, as shown in FIG. 10, this block unit generation file is provided with a file header at the beginning and a file footer at the tail end, and information in which snapshot acquisition information is organized for each block is incorporated between them.

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

Further, as shown in FIGS. 9 and 10, each block has a block header at the head and a block footer at the tail end. Management information is stored in these block headers and block footers, and these block headers and block footers sequentially chain consecutive blocks in a block unit generation file. The block header stores the address of the previous block in the block unit generation file, and the block footer stores the address of the next block in the block unit generation file.

Here, in FIGS. 9 and 10, each record is information of one employee. Each record includes the name of the employee's place of business such as "Tokyo", the name of the employee's department such as "Accounting" or "Sales", the employee name such as "Makoto Abe" or "Ryuji Kimura", "Tokyo ..." Includes employee address information such as "Chiba ...".

FIG. 11 is a data structure diagram showing a block unit generation file generated at a periodic date and time in the present embodiment.

In the present embodiment, information acquisition by snapshot is performed in chronological order. In addition, a specific date and time of each month, or a specific month and date and time for accounting and accounting can be set as a periodic date and time, and information can be automatically acquired by snapshot.

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

Here, in the present embodiment, the latest snapshot acquisition information at this point is synthesized by synthesizing the snapshot acquisition information newly acquired on a monthly basis with the past block unit generation file at a preset periodic date and time. The compressed / encrypted block unit generation file is generated. The synthesized, compressed, and encrypted block unit generation file is stored in the data storage device 40 by processing by the data management storage processing unit 30.

To generate such a synthesized block unit generation file, for example, a past block unit generation file is once decrypted, and then new snapshot acquisition information (without compression / encryption) is synthesized with this. It may be done by compressing and encrypting the synthesized one. Alternatively, the new snapshot acquisition information may be first compressed / encrypted, and then the compressed / 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 newly compressed / encrypted block unit generation file may be generated each time at a preset periodic date and time. However, in the above-mentioned synthesis, the amount of compression / encryption processing can be suppressed, and the processing speed can be improved.

As described above, each processing unit and the data storage device 40 in the data management / storage device 10 shown in FIG. 6 described above are configured in the data management / storage device 10 in FIGS. 2 and 3. However, the present embodiment is not limited to such a thing. For example, in the accounting management server device 56 of FIGS. 2 and 3, the data management storage device 10 is configured in a complex manner, and each processing unit in the data management storage device 10 shown in FIG. 6 in the accounting management server device 56 and the like. And the data storage device 40 may be configured. When the data management storage device 10 is configured in the accounting management server device 56 in a complex manner, the data storage device 40 may be provided in the database device or storage device included in the accounting management server device 56.

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

In this embodiment, in the embodiment described above, the management target DB device 12 is the accounting management server device 56, which is a database that stores at least accounting information. In addition, the above-mentioned regular date and time are set as the daily and monthly dates and times when the information is confirmed in the accounting business.

This flowchart corresponds to the entire flowchart of FIG. 5 described above. Further, the “data management and storage business process” in step S1040 of the flowchart of FIG. 5 is as shown in the entire flowchart of FIG. 7 described above. Therefore, the flowchart of FIG. 12 of this embodiment includes the entire flowchart of FIG. 7 in step S1040 of FIG.

Further, as shown in FIG. 12, in this embodiment, the “data management storage process” of step S1120 is performed by the “daily snapshot process” of step S2100 and the “monthly information synthesis process” of step S2120. It is configured. Further, the setting of the first periodic date and time and the second periodic date and time described below in this embodiment can be performed in the business setting process in step S1100 described above. The first periodic date and time may be daily, and the second periodic date and time may be monthly, but the present invention is not limited thereto. For example, the second periodic date and time may be a quarterly or annual settlement period, which is a longer cycle than the first periodic date and time.

In the "daily snapshot processing" of step S2100 described above, a snapshot of the information in the database is acquired on a daily basis (first periodic date and time), and a block unit is generated by the above-mentioned organization of block division for the acquired information. The file is generated, and the block unit generated file is compressed and 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 division organization is performed. For example, compression / encryption may be omitted, and the block unit generation file that has been processed up to the block division organization may be stored in the data storage device 40 (data management storage database). However, by performing compression / encryption, it is possible to further reduce the storage capacity required for the data storage device 40 and further improve the security security.

Further, in the "monthly information synthesis process" of step S2120 described above, the block unit generation file stored on a monthly basis (second periodic date and time) is used to generate the block unit on a monthly basis. Combine unit generation files.

This file composition of this embodiment is not specifically limited, and is not specifically limited to the block unit generation file composition process or the index data table creation process performed at the time of file composition. For example, the process of synthesizing these block unit generation files and the process of creating an index data table may be performed by only one of them in the file composition.

Further, regarding the process of synthesizing the block unit generation file at the time of file composition, for example, after decoding a plurality of block unit generation files of the past target period obtained daily, these are synthesized and synthesized. It may be done by compressing and encrypting the file. Alternatively, the plurality of block unit generation files in these target periods may be synthesized as they are without being decoded.

The creation of the index data table at the time of file composition is also not specifically limited. Regarding the process of creating this index data table, the index data table created at the time of generating multiple block unit generation files in the past target period is synthesized daily, and the index data table is created on a monthly basis. You may. Alternatively, a new monthly index data table may be created at the same time when the block unit generation file is synthesized monthly.

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

In step S1000 of FIG. 12 and step S1000 of FIG. 5 described above, various information is generated in each applicable business by the purchase management server device 50, the inventory management server device 51, the sales management server device 52, and the like. .. Among such business-specific information, various expense information related to accounting and accounting is appropriately aggregated in the accounting management server device 56 in step S1020, and a journal, general ledger, etc. are created in the accounting management server device 56. Will 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 is "2011/5/1", the detailed accounting information B1 to B3 is "2011/5/30", and the detailed accounting information C1 to C3 is "2011/5/31". This is information that is appropriately aggregated and created in 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, and the like.

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 time and the second periodic date and time in the case of automatic, and the like are appropriately performed. In this embodiment, the setting is "automatic", and regarding the periodic date and time, the date and time setting of "daily snapshot processing" (daily time setting (first periodic date and time setting)) and processing contents. , Set the monthly time of "Monthly information synthesis processing" (monthly date and time setting (second periodic date and time setting)) and processing contents.

Next, in the “daily snapshot processing” of step S2100 in step S1120, as shown by arrows D1 to D3 in FIG. 13, compressed / encrypted daily accounting information E1 to E3 (block unit generation file). ) Is generated and stored in the data storage device 40. The generation is performed on a daily basis (first periodic date and time), and daily accounting information is obtained by acquiring a snapshot of detailed accounting information in the accounting management server device 56 and organizing blocks for the acquired information. This is due to the generation of (block unit generation file) and the compression / encryption of the daily accounting information.

Subsequently, in the "monthly information synthesis process" of step S2120 in step S1120, as shown by the arrow F1 in FIG. 13, it is stored monthly (second periodic date and time) and daily as described above. The monthly accounting information (block unit generation file) for each month is synthesized from the daily accounting information. In the example of FIG. 13, the monthly accounting information of May 2011 is synthesized and generated. The processing of this synthesis and generation is performed, for example, on the first day of June 2011 of the following month.

In this embodiment, the information (daily accounting information) acquired by compression / encryption while acquiring snapshots is for each date, but since the information of the previous month is combined with the monthly accounting information at the beginning of each month. , The number of target files will be reduced when searching at a later date. Therefore, the processing amount of the search process is reduced and the processing efficiency is improved.

Here, in this embodiment, it is assumed that the accounting information is fixed on a daily basis.

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

In this embodiment, the "data management storage process" in step S1120 of the first embodiment described above is configured by the "monthly snapshot process" in step S2200, and the daily accounting information (block unit generation file) is synthesized. Not performed.

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

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

In FIG. 15, detailed accounting information K1 to K3 is "2011/5/1", detailed accounting information L1 to L3 is "2011/5/31", and detailed accounting information M1 to M3 is "2011/6/1". The detailed accounting information N1 to N3 are appropriately aggregated and created in 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, and the like in "2011/6/30". Information.

In the “monthly snapshot processing” of step S2200 of FIG. 14 of this embodiment, as shown by the arrows P1 and P2 of FIG. 15, the compressed / encrypted monthly accounting information Q1 and Q2 (block unit generation file). ) Is generated and stored in the data storage device 40. The generation is performed monthly (regular date and time), and monthly accounting information (block unit) is obtained by acquiring a snapshot of detailed accounting information in the accounting management server device 56 and organizing block divisions for the acquired information. This is due to the generation of the generated file) and the compression / encryption of the monthly accounting information.

As described above, in this embodiment, the block unit generation file is not synthesized, and a newly compressed / encrypted block unit generation file is generated each time in the “monthly snapshot processing” of step S2200. I have to. By comparing with this embodiment, it can be seen that the above-mentioned 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 there was no logic to change the data, but there was no official proof of existence of the data. Also, for example, the snapshot 62N on day N and the snapshot 62N + 1 on day N + 1 were not chained, and even if they were deleted, they could not be proved.

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

Therefore, in the first embodiment of the present invention, as shown in FIG. 17, the transaction data 60 within the predetermined unit period (here, N days on the current day) is subjected to the time unit before the time unit (here, N-1 on the previous day). By adding the time stamp 66 to the hash value 64N-1 of the day), the public existence is proved by the time stamp 66, and the snapshot is also chained so that the transaction data 60 is not deleted (the transaction data 60 is not deleted). Completeness) can be proved.

Hereinafter, the processing procedure of the first embodiment will be described with reference to FIG.

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

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

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

Then, the process proceeds to step S1430 to obtain a snapshot 62N with a time stamp 66 added.

In this way, not only the official existence proof is secured by the time stamp 66, but also the snapshots 62N, 62N + 1, 62N + 2, ... Are chained, the deletion of the transaction data 60 can be detected, and the integrity is ensured. Will be done.

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

In this second embodiment, as shown in FIG. 19, the hash value 64N of the snapshot 62N including the transaction data 60 of the time unit (here, the N day of the day), which is a plurality of continuous time units, , The hash value 64N-1 of the snapshot of the time unit before the predetermined time unit (here, N-1 day of the previous day) is used as the XAdES file 70N of the N day, and the public existence is proved by the time stamp 72. , The snapshot 62N is chained to detect the deletion of the transaction data 60 so that the integrity is ensured.

The processing procedure of this embodiment is shown in FIG.

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

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

Then, in step S1520, a Manifest file 74 in XML format 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 to which the electronic signature 78 and the time stamp 72 are added returned from the time stamp server 76 is obtained, and data management is performed together with the original file 80. Store in the storage device 10. As a result, the official existence proof and completeness 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 storage target is not limited to accounting information.

1 ... Network 5 ... Client device 10 ... Data management storage device 12 ... Managed database device (managed server device)
22 ... Snapshot processing unit 24 ... Blocking processing unit 26 ... Block-specific compression / encryption processing unit 28 ... Index data table creation processing unit 30 ... Data management storage processing unit 32 ... Block-specific decryption processing unit 34 ... Browsing processing unit 36 ... Block search processing unit 40 ... Data storage device 50 ... Purchase 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 ... Timestamp 70N, 70N + 1, 70N + 2 ... XAdES file 74 ... Manifest file 76 ... Timestamp server 78 ... Electronic signature 80 ... Original file

Claims (8)

In the data management saving method, the information of the managed database in which the data generated in time series is stored is manually or automatically periodically snapshotted and saved.
Calculate the hash value of the data in the time unit before the predetermined time unit at least.
A time stamp is added to the hash value of the data in the time unit before the time unit and the data in the time unit.
A data management storage method characterized by chaining between snapshots. The hash value of the data in the time unit before the time unit is snapshotted together with the data in the time unit.
Send the snapshot to the time stamp server
The data management storage method according to claim 1, wherein a snapshot with a time stamp is obtained. The data of the time unit and the data of a plurality of consecutive time units including the data of the time unit before the time unit are snapshotted.
A Manifest file of hash values of a plurality of consecutive time unit data is created.
Send the Manifest file to the time stamp server and
The data management storage method according to claim 1, wherein an XAdES file for a predetermined time unit to which an electronic signature and a time stamp are added is obtained. In a data management storage device that manually or automatically periodically snapshots and saves information in a managed database that stores data that occurs in time series.
A means for calculating a hash value of data in a time unit prior to the predetermined time unit, and
A hash value of data in a time unit prior to the time unit and a means for adding a time stamp to the data in the time unit are provided.
A data management and storage device characterized in that snapshots are chained together. A means for snapshotting the hash value of the time unit data before the time unit together with the time unit data.
A means for sending the snapshot to a time stamp server.
The data management storage device according to claim 4, wherein a snapshot with a time stamp is obtained. A means for snapshotting the data of the time unit and a plurality of consecutive time unit data including the data of the time unit before the time unit.
A means for creating a Manifest file of hash values of a plurality of consecutive time unit data, and
A means for sending the Manifest file to a time stamp server is provided.
The data management storage device according to claim 4, wherein an XAdES file for a predetermined time unit to which an electronic signature and a time stamp are added can be obtained. A computer program for causing a computer to execute the data management storage method according to any one of claims 1 to 3. A computer program for operating a computer as a data management storage device according to any one of claims 4 to 6.