JP2014130575A - Data coordination system, control method thereof, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a mechanism capable of suitably transmitting a deletion instruction of data from a coordination-source server to a coordination-destination server on the basis of a history that is saved as the data is deleted from a database of the coordination-source server.SOLUTION: A coordination-source server 101 deletes data from a database on receiving a deletion request for the data from a client terminal 104 or system management terminal 103. As the deletion request is made, if the deletion has been instructed by a user from the client terminal 104, an operation history is left. The coordination-source server 101 transmits a deletion request only for data in the operation history when instructing a coordination-destination servier 102 to delete data as well.

Description

  The present invention relates to database data management, and more particularly, to a data linkage system capable of determining and appropriately linking data to be linked between different databases, and a control method and program thereof.

  Conventionally, a database has been utilized for use in a company system or the like. In the database, various data for use in a company system are stored in the database, and editing operations such as registration, update, and deletion are performed as necessary.

  Basically there is not one such database. A database for backup is prepared so that even if a failure occurs in this database, the business of the company is not affected. The backup database appropriately updates the data reflected in the main database by night batches or the like. When a failure occurs in the main database, the system administrator can switch to the backup database and restore the main database.

  As a mechanism for creating such a backup database, the following Patent Document 1 discloses that update record data of an update source table is updated in real time in an update destination database and an update source database having different logical structures. And a mechanism for transferring unreflected update record data stored in the update source table after restoration when the update destination database is down.

  Further, in Patent Document 2 below, in a distributed computing environment, in order to ensure consistency among a plurality of databases even if some servers are stopped, the database is generated according to the SQL statement issued to the main server. A mechanism is disclosed in which a file storing the SQL statement is stored in the main server, and when the sub server is activated, the file is transferred and the SQL statement stored in the file is executed.

JP 2000-194717 A JP 2001-265635 A

  In recent years, in addition to the core system that plays a central role in corporate operations and services, system users (end users) can directly use information accumulated in the core system and There are cases where an information system is constructed for the purpose of processing and editing according to the required use.

  When there are a plurality of such physically different databases, it is necessary to perform daily data linkage from the backbone system in which business data is stored to the information system in order to maintain data consistency. For example, as shown in FIG. 14, when a registration, update, or deletion of data is requested from the client terminal to the server of the core system, the registration, update, or deletion of the data is performed, and then the change contents are transferred to the server of the information system. Transfer is performed. In this way, data can be stored in the information system, and data can be browsed, processed, analyzed, etc. using it.

  In order to realize this cooperation, in the conventional prior art, data stored in the backbone system is often simply linked directly to the information system, but the information system varies depending on the usage requirements of the service user. There are cases where data retention requirements differ between the backbone system and the information system. In this case, since the requirement of the information system cannot be satisfied by the conventional simple linkage, it is necessary to construct a dedicated system capable of performing the data linkage satisfying different holding requirements.

  Give examples of data retention requirements. For example, a backbone system has a database that plays a central role in business and services of a company. Since this database accumulates enormous amounts of business data every day, data that satisfies specific conditions for a certain period of time can be physically stored to suppress data enlargement, eliminate waste data, and speed up processing. The process of deleting is performed. Therefore, the data retention requirement is to retain only data within a valid retention period that is individually defined. On the other hand, in the information system, the system user has a database used for the purpose of improving business efficiency and analyzing customer needs. This database is required to retain past information semipermanently. Therefore, the data retention requirement is to retain all data semipermanently.

  In this way, if the data retention requirements are different, it is not possible to simply perform data linkage. If the requirements of the linkage destination database are met, linkage is performed. Processing is necessary, but if the user decides whether or not this cooperation is necessary, it becomes very inefficient when the system is operated.

  In particular, when data is physically deleted, data retention requirements must be considered. The physical deletion means that the data is deleted from the database instead of being deleted by setting a deletion flag while leaving the data as in the logical deletion.

  As shown in FIG. 15, in the physical deletion of the core system that is the cooperation source, the data enlargement is suppressed as in the case of deleting the data that has been mistakenly registered due to the input error and the data retention requirement. In order to eliminate dust data and speed up processing, there are two ways of physically deleting data that satisfies a specific condition for a certain period of time. With the conventional mechanism, when data is physically deleted from the link source database of the core system, any physical deletion is also performed from the link destination database of the information system. It was. However, the data retention requirement of the information system is to retain all data semipermanently, and physical deletion may be performed when deleting data that has been mistakenly registered due to an input error. is there. Therefore, when the database system is linked between the backbone system and the information system, there is a problem that the deficiency will occur in either database unless the data retention requirements are taken into account. It was.

  Furthermore, the data that was accidentally registered due to an input error is physically deleted, but if the physical deletion is incorrect, it has been physically deleted from both the linkage destination database and the linkage source database. There is also a problem that data cannot be restored. Since it is difficult to completely prevent human errors in user operations, a mechanism that can restore the data is desired.

  The present invention has been made in view of the above problems, and based on the history stored in response to the data being deleted from the database of the cooperation source server, the data is appropriately transmitted from the cooperation source server to the cooperation destination server. It is a first object of the present invention to provide a mechanism capable of transmitting the delete instruction.

  In addition, the present invention has been made in view of the above-described problems, and provides a mechanism for making a state in which data can be restored for a predetermined time even when a physical deletion of data is instructed by a user. This is the second purpose.

  In order to achieve the first object described above, a data linkage system of the present invention operates a linkage source server provided with a first database, a linkage destination server provided with a second database, and the first database. A data cooperation system comprising a client terminal, wherein the client terminal instructs the cooperation source server to delete data included in the first database in response to an instruction from a user An instruction unit; and a second deletion instruction unit that instructs the cooperation source server to delete data whose expiration date has expired among the data included in the first database. First deletion for executing deletion of data instructed by the first deletion instruction means or the second deletion instruction means for the first database A deletion history storage unit that stores a history of data deleted by the deletion unit in response to an instruction from the first deletion instruction unit, and the deletion of the data deleted by the first deletion unit Third deletion instruction means for transmitting to the cooperation destination server an instruction to delete data existing in the history stored by the history storage means, and the cooperation destination server is instructed by the third deletion instruction means It is characterized by comprising second deletion means for executing data deletion on the second database.

  Moreover, in order to achieve said 2nd objective, the data provided with the cooperation origin server provided with a 1st database, the cooperation destination server provided with a 2nd database, and the client terminal which operates a said 1st database In the cooperation system, the client terminal includes first physical deletion instruction means that instructs the cooperation source server to physically delete data included in the first database in accordance with an instruction from a user. The cooperation source server includes: a first physical deletion unit that executes physical deletion of data instructed by the first physical deletion instruction unit with respect to the first database; and the first physical deletion unit. A logical deletion instruction means for transmitting a logical deletion instruction for the deleted data to the cooperation destination server, and a predetermined time after the logical deletion instruction is issued by the logical deletion instruction means. And a second physical deletion instruction means for transmitting to the cooperation destination server a physical deletion instruction for the data for which the logical deletion instruction has been given by the logical deletion instruction means. Logical deletion means for executing logical deletion of data instructed by the instruction means for the second database, and physical deletion of data specified by the second physical deletion instruction means for the second database And a second physical deleting means to be executed.

  According to the present invention, when the user issues a deletion instruction, whether or not there is an operation history related to the data when the operation history is left in the cooperation source server and the deleted data is linked to the cooperation destination server. Accordingly, since it is possible to determine the necessity of cooperation, even if the data holding requirements of the cooperation destination database and the cooperation source database are different, there is an effect that the data can be appropriately linked. Even when physical deletion is instructed, logical deletion is instructed to the cooperation destination server, so that data can be restored from the cooperation destination server.

It is a lineblock diagram showing an example of data linkage system 100 in an embodiment of the present invention. FIG. 2 is a configuration diagram illustrating an example of a hardware configuration of a collaboration source server 101, a collaboration destination server 102, a system management terminal 103, and a client terminal 104 illustrated in FIG. FIG. 2 is a configuration diagram illustrating an example of a module configuration of a cooperation source server 101, a cooperation destination server 102, a system management terminal 103, and a client terminal 104 illustrated in FIG. It is a flowchart which shows the flow of a series of processes in embodiment of this invention. 4 is a configuration diagram illustrating an example of a configuration of a business data table 500 stored in a cooperation source server 101 and a cooperation destination server 102. FIG. 5 is a configuration diagram showing an example of a business data editing screen 600. FIG. It is a flowchart which shows the flow of a series of processes at the time of transmitting the request | requirement of logical deletion from a system management terminal. 5 is a configuration diagram showing an example of a data transfer target table 800 and a data transfer target column table 810. FIG. It is a flowchart which shows the detail of a logical deletion transfer process. It is a flowchart which shows the detail of a physical deletion process. 5 is a configuration diagram showing an example of an operation history table 1100. FIG. It is a block diagram which shows the flow of a series of processes at the time of requesting | requiring the deletion of business data from a system management terminal. It is a flowchart which shows the detail of a physical deletion transfer process. It is a schematic diagram showing the flow of processing for logical deletion of business data in a conventional backbone system and information system. It is the outline | summary which shows the problem in the case of operating the conventional backbone system and information system by physical deletion. It is a flowchart which shows the detail of the physical deletion process in 2nd Embodiment. It is a block diagram which shows an example of the operation history table 1100 in 2nd Embodiment. 10 is a flowchart illustrating details of physical deletion transfer processing according to the second embodiment. 12 is a flowchart illustrating details of a process of transmitting a physical deletion instruction of business data for which a certain time has elapsed after logical deletion in the second embodiment. It is a flowchart which shows the detail of the process for decompress | restoring business data in 2nd Embodiment. It is a figure which shows the process outline | summary of 2nd Embodiment.

  Hereinafter, an example of an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram illustrating an example of a system configuration of a data linkage system 100 according to the present invention. In the data linkage system 100 of the present invention, a linkage source server 101, a linkage destination server 102, and a system management terminal 103 are installed, and these devices can perform data communication with each other via a network 105 such as a LAN (Local Area Network). It is connected to the. Further, the client terminal 104-1 and the client terminal 104-2 (hereinafter referred to as the client terminal 104) are connected to the cooperation source server 101 via the network 106 such as a LAN so as to be able to perform data communication with each other. The configuration of various terminals or servers connected on the network 105 and the network 106 in FIG. 1 is an example, and it goes without saying that there are various configuration examples depending on applications and purposes.

  The cooperation source server 101 is a server for operating the backbone system. Through an application installed in the client terminal 104, registration, update, and deletion of the database managed by the backbone system are performed. The backbone system in the present embodiment will be described as a system used in corporate management work, but is not limited thereto.

  Further, the cooperation source server 101 performs data cooperation with the cooperation destination server 102. When the database is registered, updated, or deleted from the client terminal 104, the reflection of the contents operated from the client terminal 104 is instructed to the same database existing in the cooperation destination server 102. Alternatively, the same operation is performed according to a periodic request from the system management terminal 103.

  The cooperation destination server 102 is a server for operating the information system. The information system is a system for processing and analyzing data using information stored in the core system of the cooperation source server 101. Further, the information system of the cooperation destination server 102 stores the same database as that stored in the cooperation source server 101, and registration, update, and deletion of the database in response to a request from the cooperation source server 101. Execute. The information system in the present embodiment will be described as a system for processing and analyzing data, but is not limited thereto.

  The system management terminal 103 is a device that manages a database stored in the cooperation source server 101 or the cooperation destination server 102. In addition, a data deletion command for which the expiration date has passed is periodically transmitted to the cooperation source server 101.

  The client terminal 104 is a device that requests registration, update, and deletion of a database stored in the cooperation source server 101. These operations are accepted through the application installed in the client terminal 104, and the database of the core system of the cooperation source server 101 is operated.

  FIG. 2 is a diagram illustrating a hardware configuration of various terminals according to the embodiment of the present invention.

  The CPU 201 comprehensively controls each device and controller connected to the system bus 204.

  Further, the ROM 202 or the external memory 211 is necessary to realize a BIOS (Basic Input / Output System), an operating system program (hereinafter referred to as OS), which is a control program of the CPU 201, and a function executed by each server or each PC. Various programs to be described later are stored. The RAM 203 functions as a main memory, work area, and the like for the CPU 201.

  The CPU 201 implements various operations by loading a program necessary for execution of processing into the RAM 203 and executing the program.

  An input controller (input C) 205 controls input from a pointing device such as a keyboard 209 or a mouse (not shown).

  A video controller (VC) 206 controls display on a display device such as a CRT display (CRT) 210. The display device may be a liquid crystal display as well as a CRT.

  The memory controller (MC) 207 is an adapter to a hard disk (HD), flexible disk (FD) or PCMCIA card slot for storing boot programs, browser software, various applications, font data, user files, editing files, various data, and the like. Controls access to an external memory 211 such as a card-type memory connected via the.

  A communication I / F controller (communication I / FC) 208 is connected to and communicates with an external device via a network, and executes communication control processing in the network. For example, Internet communication using TCP / IP is possible.

  For example, the CPU 201 can perform display on the CRT 210 by executing outline font rasterization processing on a display information area in the RAM 203. In addition, the CPU 201 enables a user instruction with a mouse cursor (not shown) on the CRT 210.

  Various programs and the like used by the collaboration source server 101, the collaboration destination server 102, the system management terminal 103, and the client terminal 104 of the present invention to execute various processes to be described later are recorded in the external memory 211. The program is executed by the CPU 201 by being loaded into the RAM 203. Furthermore, definition files and various information tables used by the program according to the present invention are stored in the external memory 211.

  Next, a functional configuration diagram showing module configurations of the cooperation source server 101, the cooperation destination server 102, the system management terminal 103, and the client terminal 104 will be described with reference to FIG. Note that the module configurations of the various terminals or servers in FIG. 3 are merely examples, and it goes without saying that there are various configuration examples depending on applications and purposes.

  The cooperation source server 101 includes a transmission / reception control module 301, a determination control module 302, a business table management module 303, an operation history table management module 304, a data transfer management information management module 305, and a deletion module 306.

  The transmission / reception control module 301 is a module for transmitting / receiving various information to / from the cooperation destination server 102, the system management terminal 103, and the client terminal 104. The protocol for transmission / reception with each device is not particularly limited. An appropriate protocol capable of transmitting / receiving various types of information between the devices is appropriately selected.

  The determination control module 302 is a module for the cooperation source server 101 to make various determinations according to various information. An operation is performed to determine the flow of processing according to a branching condition for branching the process or an iterative end condition when the process is repeated.

  The business table management module 303 is a module for managing a business data table 500 shown in FIG. The operation history table management module 304 is a module for managing an operation history table 1100 shown in FIG. The data transfer management information management module 305 is a module for managing data transfer management information (a data transfer target table 800 and a data transfer target column table 810) shown in FIG. These management modules register, update, and delete each table in response to requests from the system management terminal 103 and the client terminal 104. Further, when registration, update, and deletion are performed, the data on which the operation is performed is read out and transmitted to the cooperation destination server 102 via the transmission / reception control module 301. Further, in response to a request from the system management terminal 103 or the client terminal 104, necessary data is read and transmitted to these devices.

  The deletion module 306 is a module for executing logical deletion or physical deletion of data registered in the database of the business data table 500 managed by the business table management module 303. The logical deletion is processing that sets a deletion flag 502 described later and regards it as deleted in the backbone system. On the other hand, physical deletion is processing that deletes data from the database. The logical deletion keeps the data, but the physical deletion is different in that the data is deleted without leaving the data.

  The cooperation destination server 102 includes a transmission / reception control module 311, a business table management module 312, and a deletion module 313.

  The transmission / reception control module 311, the business table management module 312, and the deletion module 313 have the same functions as the transmission / reception control module 301, business table management module 303, and deletion module 306 provided in the cooperation source server 101 described above.

  The system management terminal 103 includes a transmission / reception control module 321, a determination control module 322, a display control module 323, and a periodic deletion module 324.

  The transmission / reception control module 321 and the determination control module 322 have the same functions as the transmission / reception control module 321 and the determination control module 302 of the cooperation source server 101 described above.

  The display control module 323 is a module for causing the CRT 210 to display various information and screens. The CRT 210 to be displayed may be the CRT 210 provided in the system management terminal 103 or the CRT 210 connected to the system management terminal 103. Or you may display on CRT210 of the client terminal 104 through a network. The display destination is not particularly limited.

  The periodic deletion module 324 is a module for transmitting a request for periodically deleting data stored in the cooperation source server 101. Since the cooperation source server 101 operates the backbone system, it is necessary to periodically delete unnecessary data whose expiration date has passed. Therefore, the periodic deletion module 324 periodically transmits a request for deleting expired data to the cooperation source server 101.

  The client terminal 104 includes a transmission / reception control module 331, a determination control module 332, and a display control module 333.

  The transmission / reception control module 331, the determination control module 332, and the display control module 333 have the same functions as the transmission / reception control module 331, the determination control module 332, and the display control module 333 of the system management terminal 103 described above.

  Next, a series of processing performed by the cooperation source server 101 and the client terminal 104 in the embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S401, S402, steps S406 to S409, and steps S413 to S417 are performed under the control of the CPU 201 in the client terminal 104. Further, steps S403 to S405 and steps S410 to S412 are performed under the control of the CPU 201 in the cooperation source server 101.

  A program for causing the cooperation source server 101 and the client terminal 104 to execute this processing may be prepared as a part of an application installed in the cooperation source server 101 and the client terminal 104, or as an add-on program. The program may be prepared separately from the application.

  In step S <b> 401, the client terminal 104 activates the backbone system application stored in the external memory 211 of the client terminal 104. In step S <b> 402, the client terminal 104 transmits a request for acquiring business data to be displayed by the activated application to the cooperation source server 101.

  In step S <b> 403, the cooperation source server 101 receives the business data acquisition request transmitted from the client terminal 104. In step S404, the collaboration source server 101 acquires business data from the business data table 500 in response to the acquisition request. The business data is data stored in the business data table 500. One record of the business data table 500 may be business data, or data in a specific column may be business data.

  In step S405, the collaboration source server 101 transmits the business data acquired in step S404 to the client terminal 104.

  In step S <b> 406, the client terminal 104 receives the business data transmitted from the cooperation source server 101. In step S407, the client terminal 104 causes the CRT 210 of the client terminal 104 to display the business data editing screen 600 (see FIG. 6) in which the business data received in step S406 is embedded. Then, an operation from the user is accepted. The business data editing screen 600 is a screen on which the displayed business data can be searched, edited, deleted (logically deleted), and completely deleted (physically deleted). The business data editing screen 600 includes a search button 601, an edit button 602, a delete button 603, and a complete delete button 604, and executes various processes in response to pressing of these buttons. Any screen that can perform logical deletion and physical deletion is not limited to this.

  In step S408, the client terminal 104 determines whether or not logical deletion of business data has been instructed by an operation from the user. Specifically, it may be determined whether or not the delete button 603 has been pressed in a state where arbitrary business data displayed on the business data editing screen 600 is selected. The delete button 603 is a button for performing logical deletion. If it is determined that logical deletion has been instructed, the process proceeds to step S409. If not, the process proceeds to step S414.

  In step S409, the client terminal 104 acquires the business data instructed to be deleted by the user, and transmits a logical deletion request for the business data to the cooperation source server 101.

  In step S <b> 410, the cooperation source server 101 receives the business data deletion request transmitted from the client terminal 104. In step S411, the cooperation source server 101 executes logical deletion of the business data in response to the deletion request received in step S410. Logical deletion does not delete data as described above. It just sets a deletion flag. Therefore, the logical deletion request transmitted in step S409 is a deletion flag update request. When this logical deletion request is accepted, the business data deletion flag 502 stored in the business data table 500 is changed from “0” to “1”. That is, a deletion flag is set. By doing so, it is assumed that it has been deleted, and the business data remains.

  The business data table 500 (see FIG. 5) includes a table ID 511, a primary key 501, a deletion flag 502, a registration date 503, a registrant ID 504, a registration PG (program) ID 505, a registered terminal name 506, an update date 507, and an update PG (program). ) ID 508, update terminal name 509, and revision 510. The table ID 511 is information indicating an identifier for uniquely identifying the business data table 500. There are a plurality of business data tables 500 depending on purposes and the like. Therefore, the plurality of business data tables 500 are identified by the table ID 511. The table ID 511 only needs to be unique within each server. A primary key 501 indicates the contents of business data. For example, information such as account items, their amounts, and sales logistics. The deletion flag 502 is a flag for determining whether or not business data is being deleted by logical deletion. Whether or not the data has been deleted is determined based on the value of the deletion flag 502. The registration date and time 503, the registrant ID 504, the registration PGID 505, and the registration terminal name 506 are information stored when business data is registered. The date and time of registration, the user ID of the registered user, the ID of the registered program, and the terminal name of the registered client terminal 104 are stored. Similarly, the update date / time 507, the update PGID 508, and the update terminal name 509 are information stored at the time of update. The revision 510 is an item that is counted up each time data is updated, and is used in exclusive control processing at the time of data update. The configuration of the business data table 500 is an example, and other columns may be included.

  In step S412, the cooperation source server 101 transmits the processing result of the logical deletion executed in step S411 to the client terminal 104. In step S413, the client terminal 104 receives the processing result transmitted from the cooperation source server 101, and proceeds to step S414. If it is found that the process has failed, step S409 may be executed again, or an error screen may be displayed to notify the user.

  In step S414, the client terminal 104 determines whether a physical deletion of business data has been instructed by an operation from the user. Specifically, it may be determined whether or not the complete deletion button 604 has been pressed in a state where arbitrary business data displayed on the business data editing screen 600 is selected. The complete deletion button 604 is a button for performing physical deletion. If it is determined that physical deletion has been instructed, the process proceeds to step S415. If not, the process proceeds to step S416.

  In step S415, the client terminal 104 executes processing for physically deleting the selected business data. Details of the physical deletion processing are shown in FIG.

  In step S416, the client terminal 104 determines whether or not an instruction to end the application of the backbone system has been given by an operation from the user. If it is determined that the end has been instructed, the process proceeds to step S417. If not, the process returns to step S408.

  In step S417, the client terminal 104 ends the application started in step S401, and ends this series of processing.

  Next, a process for transferring logically deleted business data performed by the cooperation source server 101 and the system management terminal 103 according to the embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S701, S705, S706, S710 to S712, and S717 are performed under the control of the CPU 201 in the system management terminal 103. In addition, steps S702 to S704 and steps S707 to S709 are performed under the control of the CPU 201 in the cooperation source server 101.

  A program for causing the cooperation source server 101 and the system management terminal 103 to execute this processing may be prepared as a part of an application installed in the cooperation source server 101 and the system management terminal 103 or as an add-on program. Alternatively, it may be prepared as a program installed separately from the application.

  First, in step S701, the system management terminal 103 requests the cooperation source server 101 to acquire data transfer management information in order to acquire information of the data transfer target table 800 (see FIG. 8). The data transfer management information is information including two data transfer target tables 800 and a data transfer target column table 810. That is, an acquisition request for these two tables is transmitted.

  The data transfer target table 800 includes a table ID (transmission source) 801, a table ID (transmission destination) 802, the number of primary key items 803, a final acquisition date 804, and a final acquisition time 805. The table ID (transmission source) 801 and the table ID (transmission destination) 802 are the table ID 511 of the business data table 500 stored in the cooperation source server 101 and the table ID 511 of the business data table 500 stored in the cooperation destination server 102. It is information which shows. There are a plurality of business data tables 500 depending on the configuration of the backbone system. Therefore, this column defines the correspondence relationship between the tables stored in the cooperation source server 101 and the cooperation destination server 102, respectively. The number of primary key items 803 indicates the number of primary key items. The table ID (transmission source) 801, the table ID (transmission destination) 802, and the number of primary key items 803 are set in the data transfer target table 800 in advance. The last acquisition date 804 and the last acquisition time 805 are information indicating the year, month, date and time for which the logical deletion instruction has been given to the cooperation destination server 102.

  The data transfer target column table 810 includes a table ID (transmission source) 811 and a primary key item physical name 812. A column to be transferred in the business data table 500 of the transmission source is set. In the data transfer target column table 810, as many records as the number of main key items in each business data table 500 are created.

  In step S <b> 702, the cooperation source server 101 receives the data transfer management information acquisition request transmitted from the system management terminal 103. In step S703, the collaboration source server 101 acquires data transfer management information (data transfer target table 800, data transfer target column table 810) from the external memory 211 or the like. In step S704, the cooperation source server 101 transmits the data transfer management information acquired in step S703 to the system management terminal 103.

  In step S <b> 705, the system management terminal 103 receives the data transfer management information transmitted from the cooperation source server 101. Then, in step S706, the system management terminal 103 performs logic from the data transfer target table (transmission source) based on the data transfer management information received in step S705 to the last acquisition date 804 and the last acquisition time 805. A request is made to the cooperation source server 101 to acquire the deleted business data.

  In step S <b> 707, the cooperation source server 101 receives the logically deleted business data acquisition request transmitted from the system management terminal 103. In step S708, the cooperation source server 101 acquires the logically deleted business data from the business data table 500 stored in the external memory 211 in response to the logically deleted business data acquisition request received in step S707. . For the business data that has been logically deleted, the data transfer target table 800 in which the table ID 511 of the business data table 500 to be transferred is set to the table ID (transmission source) 801 is specified, and the final acquisition of the specified data transfer target table 800 is performed. Data updated after the capture date 804 and the last capture time 805 is acquired based on the update date 507 of the business data table 500 to be transferred. In step S709, the cooperation source server 101 transmits the business data acquired in step S708 to the system management terminal 103. If the business data logically deleted in step S708 cannot be acquired, that is, if there is no business data logically deleted after the last acquisition date 804 and the last acquisition time 805, the fact that the acquisition was not possible is transmitted. .

  In step S <b> 710, the system management terminal 103 receives the information transmitted from the cooperation source server 101. In step S711, the system management terminal 103 determines whether there is logically deleted business data according to the information acquired in step S710. If it is determined that there is logically deleted business data, the process proceeds to step S712. If not, the series of processes ends.

  In step S712, the system management terminal 103 transmits the business data transfer request received in step S710 to the cooperation source server 101.

  In step S <b> 713, the cooperation source server 101 receives the business data transfer request transmitted from the system management terminal 103. In step S714, the cooperation source server 101 executes the transfer process of the logically deleted business data received in step S713. Details of the logical deletion transfer process are shown in FIG.

  In step S715, the collaboration source server 101 updates the data transfer target table 800 stored in the collaboration source server 101. The last acquisition date 804 and the last acquisition time 805 of the data transfer target table 800 are updated to the current time. In step S716, the cooperation source server 101 transmits the processing result executed in steps S714 and S715 to the system management terminal 103.

  In step S717, the system management terminal 103 receives the processing result transmitted from the cooperation source server 101, and ends the series of processing. If it is found that the process has failed, step S712 may be executed again, or an error screen may be displayed to notify the user.

  Next, logical deletion transfer processing performed by the cooperation source server 101 and the cooperation destination server 102 in the embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S901 and S905 are processed under the control of the CPU 201 in the cooperation source server 101. In addition, each step of step S902 to step S904 is performed under the control of the CPU 201 in the cooperation destination server 102.

  A program for causing the cooperation source server 101 and the cooperation destination server 102 to execute this processing may be prepared as a part of an application installed in the cooperation source server 101, the cooperation destination server 102, or an add-on program. Alternatively, it may be prepared as a program installed separately from the application.

  First, in step S901, the cooperation source server 101 acquires the business data for which the logical deletion transfer request received in step S713 described above has been made, and transmits the logical deletion request for the business data. As described above, the logical deletion merely changes the deletion flag 502 from “0” to “1”, so that it is substantially an update request for the deletion flag 502.

  In step S <b> 902, the cooperation destination server 102 receives the logical deletion request transmitted from the cooperation source server 101. In step S903, in response to the logical deletion request received in step S902, the cooperation destination server 102 sets the deletion flag 502 for the business data in the business data table 500 stored in the cooperation destination server 102 from “0” to “ Change to 1 ”. In step S904, the processing result executed in step S903 is transmitted to the cooperation source server 101.

  In step S905, the cooperation source server 101 receives the processing result transmitted from the cooperation destination server 102, and ends the logical deletion transfer process. If it is found that the process has failed, step S901 may be executed again, or an error screen may be displayed to notify the user.

  Next, physical deletion processing performed by the client terminal 104 and the cooperation source server 101 in the embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S1001 to S1003, step S1007, step S1008, and step S1013 are processed under the control of the CPU 201 in the client terminal 104. Further, steps S1004 to S1006 and steps S1009 to S1012 are performed under the control of the CPU 201 in the cooperation source server 101.

  A program for causing the client terminal 104 and the cooperation source server 101 to execute this processing may be prepared as a part of an application installed in the client terminal 104, the cooperation source server 101, or an add-on program. The program may be prepared separately from the application.

  In step S1001, the client terminal 104 acquires a user ID for identifying the user set in the application activated in step S401 described above. The user ID may be acquired as the login ID when the application is started in step S401, or the user ID is set in advance for each client terminal 104 and may be acquired. Good.

  In step S1002, the client terminal 104 determines whether or not operation history registration is necessary based on the user ID acquired in step S1001. Specifically, since the user can be specified from the user ID, it can be determined whether or not the user is a system administrator. If it is a normal user, it is necessary to leave that the user has instructed physical deletion by leaving an operation history. However, there are cases where the system administrator wants to operate without leaving an operation history. For example, maintenance when a mismatch occurs in the business data table 500. In the present embodiment, the user is specified from the user ID, but the client terminal 104 or the system management terminal 103 may be determined based on the MAC address or the like. If it is determined that the operation history needs to be registered, the process proceeds to step S1003. If not, the process proceeds to step S1008.

  In step S <b> 1003, the client terminal 104 transmits an operation history registration request to the cooperation source server 101. The operation history registration request includes information for identifying the business data for which a physical deletion instruction has been issued. This information may be anything as long as business data for which a physical deletion instruction has been issued can be specified.

  In step S <b> 1004, the cooperation source server 101 receives the operation history registration request transmitted from the client terminal 104. In step S1005, the cooperation source server 101 registers the operation history in the operation history table 1100 (see FIG. 11) in response to the operation history registration request received in step S1004 (deletion history storage unit).

  The operation history table 1100 includes a table ID 1101, a primary key 1102, and a reflected flag 1103. The table ID 1101 stores the table ID 511 of the business data table 500 for which physical deletion is instructed. The primary key 1102 stores information indicating the primary key 501 of the business data table 500 for which physical deletion is instructed. The reflected flag 1103 stores a flag indicating whether or not the physical deletion instruction is also reflected in the cooperation destination server 102. Of the data registered in the operation history table 1100, data indicating that the reflected flag 1103 is not reflected is transferred to the cooperation destination server 102. Based on the information registered in the operation history table 1100, it is used to create an SQL statement of physical deletion data. For business data for which a physical deletion instruction has been transferred to the cooperation destination server 102, the reflected flag 1103 is updated to reflect.

  In step S <b> 1006, the cooperation source server 101 transmits the processing result executed in step S <b> 1005 to the client terminal 104.

  In step S1007, the client terminal 104 receives the processing result transmitted from the cooperation source server 101, and proceeds to step S1008. If it is found that the process has failed, step S1003 may be executed again, or an error screen may be displayed to notify the user.

  In step S1008, the client terminal 104 transmits a physical deletion instruction for the business data selected in step S414 described above to the cooperation source server 101 (first deletion instruction unit).

  In step S <b> 1009, the cooperation source server 101 receives a business data physical deletion instruction transmitted from the client terminal 104. In step S1010, the cooperation source server 101 executes physical deletion of business data in accordance with the physical deletion instruction received in step S1009 (first deletion unit). Unlike step S411, the target business data is deleted from the business data table 500 stored in the cooperation source server 101 instead of being deleted by setting a flag.

  In step S1011, since the cooperation source server 101 is physically deleted by the cooperation source server 101, a physical deletion transfer process is executed so that the cooperation destination server 102 also deletes it. Details of the physical deletion transfer process are shown in FIG.

  In step S1012, the cooperation source server 101 transmits the processing result executed in steps S1010 and S1011 to the client terminal 104.

  In step S1013, the client terminal 104 receives the processing result transmitted from the cooperation source server 101, and ends the physical deletion processing. If it is found that the process has failed, step S1008 may be executed again, or an error screen may be displayed to notify the user.

  Next, physical deletion processing periodically performed by the system management terminal 103 and the cooperation source server 101 in the embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S1201, S1202, and S1207 are processed under the control of the CPU 201 in the system management terminal 103. In addition, each step from step S1203 to step S1206 is processed under the control of the CPU 201 in the cooperation source server 101.

  A program for causing the system management terminal 103 and the cooperation source server 101 to execute this processing may be prepared as a part of an application installed in the system management terminal 103, the cooperation source server 101, or an add-on program. Alternatively, it may be prepared as a program installed separately from the application.

  First, in step S1201, the system management terminal 103 determines whether it is time to erase business data. The determination may be made based on whether or not a predetermined date and time set in the application of the system management terminal 103 has come. Alternatively, it is determined whether or not a predetermined date has elapsed since the date and time when this series of processes was executed last time. Since this series of processing is periodically executed, it is only necessary to determine whether or not it is the execution time.

  In step S1202, the system management terminal 103 determines that it is time to erase the business data, and therefore transmits a physical deletion request for business data whose expiration date has expired (second deletion instruction means).

  In step S <b> 1203, the cooperation source server 101 receives a physical deletion request for business data whose expiration date has expired, transmitted from the system management terminal 103. In step S1204, the cooperation source server 101 executes physical deletion of business data whose expiration date has expired (first deletion unit). Whether or not the expiration date has expired may be determined by referring to the registration date and time 503 of the business data table 500 and determining whether or not a predetermined period has elapsed since registration. Alternatively, the update date / time 507 may be used. Whether the expiration date after registration or the expiration date after the last update may be determined by the company. Then, the business data whose expiration date has expired is specified, and the specified business data is physically deleted.

  In step S <b> 1205, the cooperation source server 101 executes a transfer process of the business data physically deleted in the cooperation destination server 102. Details of the physical deletion transfer process are shown in FIG. Since no operation history remains when business data is deleted, no physical deletion instruction is given to the cooperation destination server 102 in the physical deletion transfer process of FIG. That is, data that has been physically deleted in the cooperation source server 101 is physically deleted in the cooperation destination server 102 that holds the data semi-permanently in order to suppress data enlargement, eliminate waste data, and speed up the processing. Not. It should be noted that a mode in which step S1205 is not executed at the time of data deletion can be considered, but when the physical deletion request is transmitted from the client terminal 104, the cooperation source server 101 performs steps S1009 to S1012 and steps S1203 to S106. As shown in FIG. 2, the system is configured to execute a predetermined series of processes. That is, when a physical deletion request is received, a module included in the cooperation source server 101 is executed. By using the present embodiment, it is possible to transmit only a necessary physical deletion instruction to the cooperation destination server 102 without touching the module.

  In step S <b> 1206, the cooperation source server 101 transmits the processing result executed in steps S <b> 1204 and S <b> 1205 to the system management terminal 103.

  In step S1207, the system management terminal 103 receives the processing result transmitted from the cooperation source server 101, and ends the series of processing. If it is found that the process has failed, step S1202 may be executed again, or an error screen may be displayed to notify the user.

  Next, physical deletion transfer processing performed by the cooperation source server 101 and the cooperation destination server 102 in the embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S1301 to S1303, step S1307, and step S1308 are performed under the control of the CPU 201 in the cooperation source server 101. In addition, each step from step S1304 to step S1306 is processed under the control of the CPU 201 in the cooperation destination server 102.

  A program for causing the cooperation source server 101 and the cooperation destination server 102 to execute this processing may be prepared as a part of an application installed in the cooperation source server 101, the cooperation destination server 102, or an add-on program. Alternatively, it may be prepared as a program installed separately from the application.

  First, in step S1301, the cooperation source server 101 acquires the operation history table 1100 stored in the cooperation source server 101. In step S1302, the cooperation source server 101 determines whether there is a record in which the reflected flag 1103 is not reflected in the operation history table 1100 acquired in step S1301. If it is determined that it exists, the process proceeds to step S1303. If not, the series of processes ends.

  In the processing of FIG. 12 described above, the system management terminal 103 periodically physically deletes the business data. This is executed in order to prevent data enlargement of the core system of the cooperation source server 101. Therefore, it is not necessary to physically delete the same data in the cooperation destination server 102. However, in the process shown in FIG. 10, physical deletion is executed in accordance with an instruction from the user. That is, it is a case where business data that has been registered due to an input error or the like is to be completely deleted. In this case, if the data is not deleted from the cooperation destination server 102, extra data may be mixed and malfunction may occur during data analysis. Therefore, if an instruction is given by the user, it is left as an operation history, and if not, no operation history is left, so in step S1302, it is determined whether or not physical deletion should also be performed from the business data table 500 of the cooperation destination server 102. Will be able to.

  In step S1303, the cooperation source server 101 transmits a physical deletion instruction for business data registered in the operation history table 1100 to the cooperation destination server 102 (third deletion instruction unit).

  In step S <b> 1304, the cooperation destination server 102 receives the physical deletion instruction transmitted from the cooperation source server 101. In step S1305, the cooperation destination server 102 physically deletes the corresponding business data from the business data table 500 stored in the cooperation destination server 102 in accordance with the physical deletion instruction received in step S1304 (second deletion). means).

  In step S1306, the cooperation destination server 102 transmits the processing result executed in step S1305 to the cooperation source server 101.

  In step S 1307, the cooperation source server 101 receives the processing result transmitted from the cooperation destination server 102. In step S1308, the cooperation source server 101 updates the reflected flag 1103 in the operation history table 1100 to the reflected state for the business data physically deleted in the cooperation destination server 102, and ends the physical deletion transfer process (deletion). History update means).

  As described above, according to the present embodiment, when a user issues a deletion instruction, an operation history is left in the cooperation source server, and the operation related to the data is performed when the deleted data is linked to the cooperation destination server. Since it is possible to determine the necessity of cooperation depending on whether or not there is a history, even if the data retention requirements of the cooperation destination database and the cooperation source database are different, it is possible to properly link the data There is an effect that can be done.

  Next, a second embodiment of the present invention will be described. In the above-described embodiment, if there is an operation history instructed by the user for physical deletion, the physical deletion instruction is transmitted from the cooperation source server 101 to the cooperation destination server 102. However, if a physical deletion is made from the cooperation destination server 102, there is a problem that the physically deleted data cannot be restored if the user gives a physical deletion instruction by mistake.

  This will be described in detail with reference to FIG. Reference numeral 2100 in FIG. 21 is a diagram showing the processing contents of the above-described embodiment. As shown in 2101, “business data A” and “business data B” are stored in the business data table 500 of the cooperation source server 101 and the cooperation destination server 102. Here, as shown in 2102, when the cooperation source server 101 receives a physical deletion request for “business data A” from the client terminal 104, the cooperation source server 101 physically deletes “business data A”. Then, an operation history is left. Since the operation history remains, in order to physically delete “business data A” also from the cooperation destination server 102, a physical deletion request is transmitted from the cooperation source server 101 to the cooperation destination server 102. Then, “business data A” is also physically deleted from the business data table 500 of the cooperation destination server 102. Depending on the timing at which a physical deletion request is transmitted from the cooperation source server 101 to the cooperation destination server 102, the physical deletion from the cooperation source server 101 is simultaneously deleted from the cooperation destination server 102. Therefore, if the user makes a physical deletion request for “business data A” by mistake, it cannot be restored.

  Therefore, in the second embodiment, the process indicated by 2110 is executed. First, as indicated by 2111, “business data A” and “business data B” are stored in the business data table 500 of the cooperation source server 101 and the cooperation destination server 102. Here, as indicated by 2112, when a physical deletion request for “business data A” is made from the client terminal 104 as in the above-described embodiment, “business data A” is sent from the business data table 500 of the cooperation source server 101. Is physically deleted. Then, the presence / absence of an operation history is determined. If there is an operation history, a logical deletion request is transmitted to the cooperation destination server 102 instead of a physical deletion request. Even if the cooperation source server 101 receives a physical deletion request from the client terminal 104, the cooperation source server 101 holds the data so that it can be restored by transmitting a logical deletion request to the cooperation destination server 102.

  Then, as indicated by 2113, “business data A” is restored from the cooperation destination server 102 if restoration is necessary. In addition, if the logical deletion is left while the physical deletion is instructed, the intention of the user who has instructed the physical deletion is not reflected. Therefore, based on the operation history, for data that has passed for a certain period of time since the logical deletion, a physical deletion request is transmitted again from the cooperation source server 101 to the cooperation destination server 102. In this way, it is possible to restore data that has been accidentally physically deleted while reliably performing physical deletion. Hereinafter, this second embodiment will be described.

  Since the system configuration, hardware configuration, and functional configuration in the second embodiment are the same as those in the above-described embodiment, description thereof will be omitted. The same reference numerals as those used in the above-described embodiment are used for the same parts as those in the above-described embodiment. Moreover, since each process shown in FIG.4, FIG.7, FIG.9 is the same also in 2nd Embodiment, description is abbreviate | omitted.

  Next, physical deletion processing performed by the client terminal 104 and the cooperation source server 101 in the second embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S1001 to S1003, step S1007, step S1008, and step S1013 are processed under the control of the CPU 201 in the client terminal 104. Further, steps S1004, S1006, S1009 to S1012, and S1601 are processed under the control of the CPU 201 in the cooperation source server 101.

  A program for causing the client terminal 104 and the cooperation source server 101 to execute this processing may be prepared as a part of an application installed in the client terminal 104, the cooperation source server 101, or an add-on program. The program may be prepared separately from the application.

  Steps S1001 to S1013 are the same as steps S1001 to S1013 in FIG. Step S1008 is a first physical deletion instruction unit, and step S1010 is a first physical deletion unit.

  In step S1601, the cooperation source server 101 registers the operation history in the operation history table 1100 illustrated in FIG. 17 in response to the operation history registration request received in step S1004.

  The operation history table 1100 illustrated in FIG. 17 includes a table ID 1101, a primary key 1102, a reflected flag 1701, a logical deletion reflection date 1702, and a physical deletion reflection date 1703. The table ID 1101 and the primary key 1102 are the same as in the above-described embodiment. The reflected flag 1701 stores a flag indicating whether or not the physical deletion instruction is reflected in the cooperation destination server 102 as in the above-described embodiment. In the second embodiment, the reflected flag 1701 stores four types of flags. First, when “0” is stored, “unreflected” is indicated. When “1” is stored, “Logical deletion reflected” is indicated. When “9” is stored, “physical deletion reflected” is indicated. If “99” is stored, “data restored” is indicated. The type of flag is merely an example, and is not limited thereto. The logical deletion reflection date and time 1702 indicates the date and time when the cooperation source server 101 requested the cooperation destination server 102 to perform logical deletion in response to a physical deletion request from the client terminal 104. The physical deletion reflection date and time 1703 indicates the date and time when the cooperation source server 101 requested the cooperation destination server 102 to perform physical deletion after the predetermined time has elapsed after the logical deletion was executed.

  In step S1601, a new record is created in the operation history table 1100, the table ID 1101 stores the table ID 511 of the business data table 500 including the data requested to be physically deleted, and the primary key 1102 stores the physical deletion request. Information indicating the primary key 501 that is the data that has been made is stored. Then, “0” is stored in the reflected flag 1701, and nothing is stored in the logical deletion reflection date 1702 and the physical deletion reflection date 1703.

  Next, physical deletion transfer processing performed by the cooperation source server 101 and the cooperation destination server 102 in the second exemplary embodiment of the present invention will be described with reference to the flowchart shown in FIG. Note that steps S1801 to S1803, step S1807, and step S1808 are processed under the control of the CPU 201 in the cooperation source server 101. In addition, each step from step S1804 to step S1806 is processed under the control of the CPU 201 in the cooperation destination server 102.

  A program for causing the cooperation source server 101 and the cooperation destination server 102 to execute this processing may be prepared as a part of an application installed in the cooperation source server 101, the cooperation destination server 102, or an add-on program. Alternatively, it may be prepared as a program installed separately from the application.

  First, in step S1801, the cooperation source server 101 acquires the operation history table 1100 stored in the cooperation source server 101. In step S1802, the cooperation source server 101 determines whether there is a record in which the reflected flag 1701 is “0”, that is, “unreflected” in the operation history table 1100 acquired in step S1801. . If it is determined that it exists, the process proceeds to step S1803. If not, the series of processes ends.

  In step S1803, the cooperation source server 101 transmits a logical deletion instruction for business data registered in the operation history table 1100 to the cooperation destination server 102 (logical deletion instruction means). In the above-described embodiment, the physical deletion instruction is transmitted here, but in the second embodiment, the logical deletion instruction is transmitted. Since the target business data is not physically deleted from the cooperation destination server 102 by transmitting the logical deletion instruction here, even if the user has instructed the physical deletion by mistake, it is restored from the cooperation destination server 102. It becomes possible.

  In step S1804, the cooperation destination server 102 receives the logical deletion instruction transmitted from the cooperation source server 101. In step S1805, the cooperation destination server 102 logically deletes the corresponding business data from the business data table 500 stored in the cooperation destination server 102 in accordance with the logical deletion instruction received in step S1804 (logical deletion means). . More specifically, a flag indicating that logical deletion has been performed is set in the business data deletion flag 502 included in the target business data table 500.

  In step S1806, the cooperation destination server 102 transmits the processing result executed in step S1805 to the cooperation source server 101.

  In step S1807, the cooperation source server 101 receives the processing result transmitted from the cooperation destination server 102. In step S1808, the cooperation source server 101 updates the reflected flag 1103 in the operation history table 1100 to “1”, that is, “logic deletion reflected” for the business data logically deleted in the cooperation destination server 102. Further, the current date and time when the logical deletion is performed is stored in the logical deletion reflection date and time 1702. When the process is completed, the physical deletion transfer process is terminated. As described above, even when a physical deletion instruction is received from the client terminal 104, a logical deletion is instructed to the cooperation destination server 102. That is, the cooperation source server 101 executes physical deletion (step S1010), while the cooperation destination server 102 executes logical deletion (step S1805).

  Next, a series of processing for physically deleting the business data logically deleted in step S1805, which is periodically executed by the cooperation source server 101, will be described with reference to FIG. Note that steps S1901 to S1903, step S1907, and step S1908 are performed under the control of the CPU 201 of the cooperation source server 101. In addition, each step from step S1904 to step S1906 is processed under the control of the CPU 201 of the cooperation destination server 102.

  First, in step S1901, the cooperation source server 101 acquires the operation history table 1100 shown in FIG. In step S1902, the cooperation source server 101 has an operation history stored in the operation history table 1100 acquired in step S1901, and a certain time has elapsed since the logical deletion was executed in step S1805 described above. It is determined whether or not to do. More specifically, among records in which the reflection flag 1701 of the operation history table 1100 shown in FIG. 17 is “1”, that is, “logical deletion reflection completed”, a certain time has elapsed from the logical deletion reflection date 1702. Determine whether there is a record.

  In FIG. 18 described above, logical deletion is requested to the cooperation destination server 102, but since the request for physical deletion is originally received from the client terminal 104, the cooperation destination server 102 must also be requested to perform physical deletion. I must. Therefore, the business data that has passed a certain period of time after logical deletion is physically deleted from the cooperation destination server 102 to reflect the user's intention. In other words, business data can be restored by logical deletion for a certain period of time, and physical deletion is performed after a certain period of time, so that even if the user accidentally instructs physical deletion, it is restored for a certain period of time. It is possible to perform the physical deletion with certainty.

  Note that the predetermined time described above is an arbitrary time set in the cooperation source server 101 in advance. Any time can be used as long as you have a grace period to restore.

  If it is determined that a certain time has elapsed since the logical deletion was executed, the process proceeds to step S1903. If it is determined that there is no one that has passed a certain time since the logical deletion was executed, this series of processing ends.

  In step S1903, the cooperation source server 101 transmits a business data physical deletion request for which a predetermined time has elapsed since the logical deletion to the cooperation destination server 102 (second physical deletion instruction unit). Since the business data to be physically deleted can be identified from the table ID 1101 and the main key 1102 of the operation history table 1100 shown in FIG. 17 and further from the data transfer target table 800, a request may be issued based on them.

  In step S1904, the cooperation destination server 102 receives the physical deletion request transmitted from the cooperation source server 101. In step S1905, the cooperation destination server 102 executes physical deletion of the requested target business data (second physical deletion unit).

  In step S1906, the cooperation destination server 102 transmits the processing result executed in step S1905 to the cooperation source server 101.

  In step S1907, the cooperation source server 101 receives the processing result transmitted from the cooperation destination server 102. In step S1908, the cooperation source server 101 updates the reflected flag 1103 of the operation history table 1100 to “9”, that is, “physical deletion reflected” for the business data physically deleted by the cooperation destination server 102. Further, the current date and time of physical deletion are stored in the physical deletion reflection date and time 1703. When the processing is completed, the series of processing ends. As described above, when there is an operation history in which a physical deletion instruction has been given by the user and a predetermined time has elapsed since a logical deletion request was issued to the cooperation destination server 102 in response to the physical deletion instruction The physical deletion can be surely executed by requesting the execution of the physical deletion again.

  Next, a series of processing for restoring the business data from the cooperation destination server 102 when the user accidentally requests physical deletion will be described with reference to FIG. Note that steps S2001 and S2013 are performed under the control of the CPU 201 of the client terminal 104. Further, steps S2002 to S2004 and steps S209 to S2012 are processed under the control of the CPU 201 of the cooperation source server 101. In addition, each step from step S2005 to step S2008 is performed under the control of the CPU 201 of the cooperation destination server 102.

  First, in step S2001, the client terminal 104 transmits to the cooperation source server 101 a request for restoring business data that has been deleted by mistake. An input of information for identifying business data that has been deleted by mistake from the user is received, and a restoration request is transmitted to the cooperation destination server 102 in accordance with the information.

  In step S2002, the cooperation source server 101 receives the business data restoration request transmitted from the client terminal 104. In step S2003, the cooperation source server 101 determines whether the reflected flag 1103 of the business data requested to be restored is “1”, that is, “logical deletion has been reflected”. If it is another flag, since it cannot be restored, such a determination is made in step S2002. If it is determined that the reflected flag 1103 is “Logical deletion reflected”, the process proceeds to step S2004. If it is determined that the reflected flag 1103 is not “logical deletion reflected”, the process advances to step S2012.

  In step S <b> 2004, the cooperation source server 101 transmits a business data acquisition request for which a restoration request has been made at the client terminal 104 to the cooperation destination server 102.

  In step S2005, the cooperation destination server 102 receives the business data restoration request requested from the cooperation source server 101. In step S2006, the cooperation destination server 102 restores the business data requested to be restored. More specifically, the deletion flag 502 of the target business data is canceled, that is, the logical deletion is canceled. In this way, the business data is restored in the cooperation destination server 102. If restoration is performed in the cooperation source server 101, consistency cannot be obtained unless the cooperation destination server 102 also restores in synchronization therewith. Therefore, in step S2006, the target business data is restored in the cooperation destination server 102.

  In step S2007, the cooperation destination server 102 acquires the business data restored in step S2005 from the business data table 500. In step S2008, the cooperation destination server 102 transmits the acquired business data to the cooperation source server 101.

  In step S2009, the cooperation source server 101 receives the business data transmitted from the cooperation destination server 102. In step S2010, the collaboration source server 101 adds the business data received in step S2009 to the business data table 500. More specifically, the business data table 500 requested to be restored by the user is specified, and a new record is created in the business data table 500. Then, the received business data is stored in a newly created record. Thereby, the restoration from the cooperation source server 101 is completed.

  In step S2011, the cooperation source server 101 updates the operation history table 1100 illustrated in FIG. More specifically, among the records stored in the operation history table 1100 of FIG. 17, the reflected flag 1701 of the record indicating the operation history related to the restored business data is set to “99”, that is, the flag indicating “data restored”. Update to By doing so, it is possible to keep a history of restoring data. In this embodiment, the operation history of the restored business data is kept, but may be deleted. By doing so, enlargement of the operation history table 1100 can be prevented.

  In step S2012, the cooperation source server 101 transmits the processing result executed in steps S2003 to S2011 to the client terminal 104.

  In step S2013, the client terminal 104 receives the processing result transmitted from the cooperation source server 101, and ends this series of processing.

  As described above, according to the second embodiment, even when physical deletion is instructed, data is restored from the cooperation destination server in order to instruct logical cooperation to the cooperation destination server. Is possible.

  The present invention can be implemented as a system, apparatus, method, program, storage medium, or the like, and can be applied to a system including a plurality of devices. You may apply to the apparatus which consists of one apparatus.

  Note that the present invention includes a software program that implements the functions of the above-described embodiments directly or remotely from a system or apparatus. The present invention also includes a case where the system or the computer of the apparatus is achieved by reading and executing the supplied program code.

  Accordingly, since the functions of the present invention are implemented by computer, the program code installed in the computer also implements the present invention. In other words, the present invention includes a computer program itself for realizing the functional processing of the present invention.

  In that case, as long as it has the function of a program, it may be in the form of object code, a program executed by an interpreter, script data supplied to the OS, and the like.

  Examples of the recording medium for supplying the program include a flexible disk, hard disk, optical disk, magneto-optical disk, MO, CD-ROM, CD-R, and CD-RW. In addition, there are magnetic tape, nonvolatile memory card, ROM, DVD (DVD-ROM, DVD-R), and the like.

  As another program supply method, a browser on a client computer is used to connect to an Internet home page. The computer program itself of the present invention or a compressed file including an automatic installation function can be downloaded from the homepage by downloading it to a recording medium such as a hard disk.

  It can also be realized by dividing the program code constituting the program of the present invention into a plurality of files and downloading each file from a different homepage. That is, a WWW server that allows a plurality of users to download a program file for realizing the functional processing of the present invention on a computer is also included in the present invention.

  In addition, the program of the present invention is encrypted, stored in a storage medium such as a CD-ROM, distributed to users, and key information for decryption is downloaded from a homepage via the Internet to users who have cleared predetermined conditions. Let It is also possible to execute the encrypted program by using the downloaded key information and install the program on a computer.

  Further, the functions of the above-described embodiments are realized by the computer executing the read program. In addition, based on the instructions of the program, an OS or the like running on the computer performs part or all of the actual processing, and the functions of the above-described embodiments can also be realized by the processing.

  Further, the program read from the recording medium is written in a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer. Thereafter, the CPU of the function expansion board or function expansion unit performs part or all of the actual processing based on the instructions of the program, and the functions of the above-described embodiments are realized by the processing.

  The above-described embodiments are merely examples of implementation in carrying out the present invention, and the technical scope of the present invention should not be construed as being limited thereto. That is, the present invention can be implemented in various forms without departing from the technical idea or the main features thereof.

DESCRIPTION OF SYMBOLS 100 Data cooperation system 101 Cooperation origin server 102 Cooperation destination server 103 System management terminal 104 Client terminal 105 Network 106 Network 201 CPU
202 RAM
203 ROM
204 System Bus 205 Input Controller 206 Video Controller 207 Memory Controller 208 Communication I / F (Interface) Controller 209 Input Device 210 Display Device 211 External Memory

Claims (9)

A data collaboration system comprising a collaboration source server comprising a first database, a collaboration destination server comprising a second database, and a client terminal for operating the first database,
The client terminal is
In response to an instruction from a user, a first deletion instruction means for instructing the cooperation source server to delete data included in the first database;
A second deletion instruction means for instructing the cooperation source server to delete the expired data among the data included in the first database;
The cooperation source server
First deletion means for executing deletion of data instructed by the first deletion instruction means or the second deletion instruction means to the first database;
A deletion history storage unit that stores a history of data deleted by the deletion unit in response to an instruction from the first deletion instruction unit;
A third deletion instruction means for transmitting, to the cooperation destination server, a deletion instruction of data existing in the history stored in the deletion history storage means among the data deleted by the first deletion means;
The cooperation destination server is
A data linkage system comprising: a second deletion unit that executes deletion of data instructed by the third deletion instruction unit with respect to the second database. The cooperation source server
A deletion history update unit that updates the history of deletion performed by the second deletion unit as reflected;
The third deletion instruction unit transmits an instruction to delete unreflected data in the history stored by the deletion history storage unit to the cooperation destination server. The data linkage system described.   The data linkage system according to claim 1, wherein the deletion history storage unit determines whether or not to store a deletion history in accordance with a user who has issued a deletion instruction.   4. The data linkage system according to claim 1, wherein the deletion in the first deletion unit and the second deletion unit is physical deletion. 5. A method for controlling a data collaboration system comprising a collaboration source server comprising a first database, a collaboration destination server comprising a second database, and a client terminal for operating the first database,
A first deletion instruction step in which a first deletion instruction means of the client terminal instructs the cooperation source server to delete data included in the first database in response to an instruction from a user;
A second deletion instruction step in which the second deletion instruction means of the client terminal instructs the cooperation source server to delete the expired data among the data included in the first database; A first deletion step in which the first deletion unit of the cooperation source server executes the deletion of the data instructed in the first deletion instruction step or the second deletion instruction step with respect to the first database. When,
A deletion history storage unit that stores a history of data deleted by the deletion unit in response to an instruction from the first deletion instruction step;
The third deletion instruction means of the cooperation source server transmits, to the cooperation destination server, a deletion instruction of data existing in the history saved in the deletion history saving step among the data deleted in the first deletion step. A third deletion instruction step to perform,
The second deletion means of the cooperation destination server includes a second deletion step of executing deletion of the data instructed in the third deletion instruction step with respect to the second database. Control method of data linkage system. A program capable of executing a control method of a data collaboration system comprising a collaboration source server comprising a first database, a collaboration destination server comprising a second database, and a client terminal for operating the first database,
The client terminal is
In response to an instruction from a user, a first deletion instruction means for instructing the cooperation source server to delete data included in the first database;
Causing the cooperation source server to function as a second deletion instruction means for instructing deletion of data whose expiration date has expired among the data included in the first database;
The linkage source server
First deletion means for executing deletion of data instructed by the first deletion instruction means or the second deletion instruction means to the first database;
A deletion history storage unit that stores a history of data deleted by the deletion unit in response to an instruction from the first deletion instruction unit;
Among the data deleted by the first deletion means, function as a third deletion instruction means for sending a deletion instruction of data existing in the history stored by the deletion history storage means to the cooperation destination server,
The cooperation destination server is
A program that causes a deletion of data instructed by the third deletion instruction unit to function as a second deletion unit that executes the deletion on the second database. A data collaboration system comprising a collaboration source server comprising a first database, a collaboration destination server comprising a second database, and a client terminal for operating the first database,
The client terminal is
In accordance with an instruction from a user, the first physical deletion instruction means for instructing the cooperation source server to physically delete data included in the first database,
The cooperation source server
First physical deletion means for executing physical deletion of data instructed by the first physical deletion instruction means on the first database;
Logical deletion instruction means for transmitting an instruction for logical deletion of data deleted by the first physical deletion means to the cooperation destination server;
A second instruction for transmitting a physical deletion instruction of data for which a logical deletion instruction has been given by the logical deletion instruction means to the cooperation destination server when a predetermined time has elapsed after the logical deletion instruction means has instructed the logical deletion instruction; A physical deletion instruction means, and
The cooperation destination server is
Logical deletion means for executing logical deletion of data instructed by the logical deletion instruction means on the second database;
A data linkage system comprising: a second physical deletion unit that executes physical deletion of data instructed by the second physical deletion instruction unit with respect to the second database. A method for controlling a data collaboration system comprising a collaboration source server comprising a first database, a collaboration destination server comprising a second database, and a client terminal for operating the first database,
A first physical deletion instruction step in which the first physical deletion instruction means of the client terminal instructs the cooperation source server to physically delete the data included in the first database in response to an instruction from a user; When,
A first physical deletion step in which a first physical deletion unit of the cooperation source server executes physical deletion of the data instructed in the first physical deletion instruction step with respect to the first database;
A logical deletion instruction step in which the logical deletion instruction means of the cooperation source server transmits a logical deletion instruction of the data deleted in the first physical deletion step to the cooperation destination server;
When the second physical deletion instructing unit of the cooperation source server gives a logical deletion instruction in the logical deletion instructing step and a predetermined time has elapsed, the data of the logical deletion instructed in the logical deletion instructing step A second physical deletion instruction step for transmitting a physical deletion instruction to the cooperation destination server;
A logical deletion step in which the logical deletion means of the cooperation destination server executes logical deletion of the data instructed in the logical deletion instruction step on the second database;
A second physical deletion step in which the second physical deletion unit of the cooperation destination server executes a physical deletion of the data instructed in the second physical deletion instruction step to the second database. A control method of a data linkage system characterized by the above. A program capable of executing a control method of a data collaboration system comprising a collaboration source server comprising a first database, a collaboration destination server comprising a second database, and a client terminal for operating the first database,
The client terminal is
In response to an instruction from a user, the server functions as a first physical deletion instruction unit that instructs the cooperation source server to physically delete data included in the first database,
The linkage source server
First physical deletion means for executing physical deletion of data instructed by the first physical deletion instruction means on the first database;
Logical deletion instruction means for transmitting an instruction for logical deletion of data deleted by the first physical deletion means to the cooperation destination server;
A second instruction for transmitting a physical deletion instruction of data for which a logical deletion instruction has been given by the logical deletion instruction means to the cooperation destination server when a predetermined time has elapsed after the logical deletion instruction means has instructed the logical deletion instruction; Function as a physical deletion instruction means,
The cooperation destination server is
Logical deletion means for executing logical deletion of data instructed by the logical deletion instruction means on the second database;
A program for causing a physical deletion of data instructed by the second physical deletion instruction means to function as a second physical deletion means for executing the data deletion on the second database.

Images