HISTORY CREATION SERVICE PROVIDING DEVICE, HISTORY CREATION SERVICE PROVIDING METHOD, AND PROGRAM

Abstract

To provide a history creation service providing device that creates an update history according to table update managed by a database service, and to maintain consistency in the history even if a notified event is data deletion.SOLUTION: A history creation service providing device, when update processing of data in a database is performed in response to a request from a terminal device, receives an update event of the update processing of the data and creates an update history based on the update event, and comprises: acquisition means that acquires an occurrence time of the update event and the time of the data update processing before the occurrence of the update event; creation means that, when a type of the update event is deletion of data, performs correction based on the occurrence time of the update event, the time of the data update processing before the occurrence of the update event, and a predetermined correction value, and creates a correction candidate value; and update means that adds the correction candidate value to items in the update history.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a history creation service providing device, a history creation service providing method, and a program for creating an update history based on an update event. [Background technology]

[0002] Conventionally, stream processing has been used to notify in real time of events that occur sequentially as a result of data processing on devices such as PCs, smartphones, embedded devices, and servers to other devices connected via a network (see Patent Document 1).

[0003] Furthermore, with the spread of cloud services, cloud service vendors are now providing stream services that notify other services of events that occur on one service.

[0004] For example, some cloud vendors provide a stream service that notifies you of update events via a stream when data is updated in a table managed by a database service. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2014-191637 A Summary of the Invention [Problem to be solved by the invention]

[0006] When a table update managed by a database service is notified to a user service as an event by a stream service, depending on the stream service, there may be a difference or difference in accuracy between the table update time and the event notification time. In this case, the user service receiving the event recognizes that the event notification time is set to a value that includes a certain degree of error in the data update time. Therefore, when a user service wants to realize a use case in which this time error cannot be tolerated, a method is often used in which an update time attribute that sets the data update time is added to the table and the attribute value after the update is notified together with the event information. With this method, since the update time is notified as the event information after the update, it is possible to realize a use case in which an error cannot be tolerated for data addition or data modification to a table by using the notified update time. However, if the event is data deletion, the target data is deleted from the table, so the update time attribute cannot be set and the update time is not notified.

[0007] One possible solution would be to use the event notification time instead of the update time attribute value only when data is deleted, but as mentioned above, the event notification time received by the user service contains an error, so there is a possibility that the order of the update time attribute value notified when data is added or changed before the data is deleted and the notification time when the data is deleted may be reversed.

[0008] As a result, when a user service creates an event history based on the notified events, the order of the deletion event in the history and the addition or modification event that occurred immediately before the deletion may be swapped, which could result in the history becoming inconsistent.

[0009] The present invention has been made in consideration of the above-mentioned problems, and aims to maintain the consistency of the history in a history creation service providing device that creates an update history in response to table updates managed by a database service, even if the notified event is data deletion. [Means for solving the problem]

[0010] A history creation service providing device that, when a data update process of a database is performed in response to a request from a terminal device, receives an update event of the data update process and creates an update history based on the update event, notification An acquisition means for acquiring a time and a time of an update process of the data before the occurrence of the update event, and when the type of the update event is data deletion, based on the time of the update process of the data before the occurrence of the update event and a predetermined correction value. tree A generating means for generating a correction candidate value; When the correction candidate value is equal to or greater than the notification time of the update event, The correction candidate value Event occurrence time attribute To and if the correction candidate value is not equal to or greater than the value of the notification time of the update event, sets the notification time of the update event to the event occurrence time attribute. and a setting means. Effect of the Invention

[0011] According to the present invention, in a history creation service providing device that creates an update history in response to table updates managed by a database service, it is possible to maintain the consistency of the history even if the notified event is data deletion. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram showing an example of a functional configuration of a first embodiment; [Diagram 2] Flow diagram of license addition processing performed in the first embodiment. [Diagram 3] Flow diagram of license change processing performed in the first embodiment [Figure 4] Flow diagram of license deletion processing performed in the first embodiment. [Diagram 5] Flow diagram of license acquisition processing performed in the first embodiment [Figure 6] Flow diagram of history update processing performed in the first embodiment [Figure 7] Display examples of a user list screen and a license information screen (before and after adding a service) used in the first embodiment [Figure 8] Display examples of license addition screen, change screen, and deletion screen used in the first embodiment [Figure 9] Examples of license management table and history table used in the first embodiment [Figure 10] Example of license history file used in the first embodiment [Figure 11] Examples of addition events, change events (increase and decrease in the number of licenses), and deletion events used in the first embodiment [Figure 12] FIG. 13 is a block diagram showing an example of a functional configuration of a second embodiment. [Figure 13] Example of License Management Table Used in the Second Embodiment [Figure 14] Example of a deletion event used in the second embodiment [Figure 15] Example of license history file used in the second embodiment [Figure 16] Flow diagram of history update processing performed in the second embodiment [Figure 17] FIG. 13 is a block diagram showing an example of a functional configuration of a third embodiment. [Figure 18] Example of License Management Table Used in Third Embodiment [Figure 19] Example of a deletion event used in the third embodiment [Figure 20] Example of license history file used in the third embodiment [Figure 21] Flow diagram of history update processing performed in the third embodiment DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, a preferred embodiment of the present invention will be described with reference to the accompanying drawings. Note that the embodiment described below shows an example of a specific implementation of the present invention, and is one of the specific embodiments of the configuration described in the claims.

[0014] (First embodiment) The image display device according to this embodiment will be described with reference to the block diagram of FIG.

[0015] A registration service providing device 100, a history acquisition service providing device 110, a history creation service providing device 120, a terminal device 130, a database service providing device 140, and an event notification service providing device 150 are connected to a network.

[0016] Moreover, the configuration allows mutual data communication.

[0017] Next, the registration service providing device 100 will be described. The registration service providing device 100 is a device that operates a registration service that registers data in a table managed by the database service providing device 140 in response to a request from the terminal device 130. In this embodiment, the number of licenses that allow a specific user to use a specific product is assumed as the data to be registered. The CPU 101 controls the operation of the entire registration service providing device. The memory 102 provides a working area that the CPU 101 uses when executing various processes. Of the components that make up the registration service providing device 100, each component except the CPU 101 and the memory 102 may be configured as hardware or software. Examples of the registration service providing device 100 include a PC, a server, and a virtual server on the cloud.

[0018] Next, the history acquisition service providing device 110 will be described. The history acquisition service providing device 110 is a device that operates a history acquisition service that acquires data update history from a table managed by the database service providing device 140 in response to a request from the terminal device 130 and transmits the history to the terminal device 130. In this embodiment, the update history is a history of an increase or decrease in the number of licenses for a product that the user can use, and it is assumed that the format of the data that transmits the history to the terminal device is CSV format.

[0019] The CPU 111 controls the overall operation of the history acquisition service providing device. The memory 112 provides a working area that the CPU 111 uses when executing various processes.

[0020] Of the components constituting the history acquisition service providing device 110, each component except for the CPU 111 and the memory 112 may be configured as hardware or software. Examples of the history acquisition service providing device 110 include a PC, a server, and a virtual server on the cloud.

[0021] Next, the database service providing device 140 will be described. The database service providing device 140 manages the data items requested for registration by the registration service providing device 100 in a table. In this embodiment, since the number of licenses for the product available to the user is assumed as a data item, this table is called a license management table. Fig. 9A is an example of the license management table.

[0022] The license management table is made up of the following attributes: user ID 901 , service ID 902 , contract ID 903 , current number of licenses 904 , and update date and time 905 .

[0023] In this embodiment, except for the update date and time 905, attributes specific to license management are used, but other attributes may be used depending on the embodiment.

[0024] The user ID 901 is an attribute that indicates which user is assigned the license, and a unique value is set for each user.

[0025] The service ID 902 is an attribute that indicates which product the license is assigned to, and a unique value is set for each product.

[0026] A pair of a user ID 901 and a service ID 902 is a key for this table and is unique within the table. A contract ID 903 is an attribute that indicates which contract ultimately allocates the number of licenses, and a unique value is set for each contract. A current number of licenses 904 is the number of licenses for the service currently allocated to the user.

[0027] The update date and time 905 is the date and time when this data item (row) was last updated.

[0028] Also, when requested by the history acquisition service providing device 110, it returns a list of data registration histories managed in a table separate from the data management table.

[0029] In this embodiment, since the update history of the license management table is assumed as the data registration history, this table is called a license history table. Fig. 9B shows an example of the license history table. The license history table is configured with the following attributes: event ID 911, user ID 912, service ID 913, contract ID 914, number of differential licenses 915, and event occurrence time 916.

[0030] Furthermore, one data item (row) of the license history table is added every time one data item (row) of the license management table is updated.

[0031] In this embodiment, except for the event occurrence time 916, attributes specific to license management are used, but other attributes may be used depending on the embodiment.

[0032] The event ID 911 is a key for identifying a data item (row) in the table, and is unique within the table.

[0033] The user ID 912, service ID 913, and contract ID 914 have the same values ​​as the updated data items in the license management table.

[0034] The difference license number 915 is the difference obtained by subtracting the value before the change from the value after the change in the current license number 904 in the license management table.

[0035] The event occurrence time 916 is the time when this data update occurred.

[0036] The CPU 141 controls the overall operation of the database service providing device.

[0037] The memory 142 provides a working area used when the CPU 141 executes various processes. Of the components constituting the database service providing device 140, each component except for the CPU 141 and the memory 142 may be configured with hardware or software. Examples of the database service providing device 140 include a PC, a server, and a virtual server on the cloud.

[0038] In this embodiment, a general database service is assumed, but any type of service may be used as long as it is a service capable of storing data.

[0039] Next, a description will be given of the event notification service providing device 150. When a table managed by the database service providing device 140 is updated, the event notification service providing device 150 transmits the update contents to the history creation service providing device 120 as one event for each data item.

[0040] 11(A), (B), (C), and (D) are examples in which an event notified from the event notification service providing device 150 is described using keys and values ​​in the JSON format.

[0041] An identifier that uniquely identifies an event is set in the event ID.

[0042] The event type is set to "INSERT" when a data item is added, "MODIFY" when an item is updated, and "REMOVE" when an item is deleted. The notification time is set to the time when the event was generated. The pre-update data is set to the values ​​of each attribute included in the data items before the update of the license management table in key-value format.

[0043] In the post-update data, the value of each attribute included in the data item of the post-update license management table is set in the form of a key and a value. The CPU 151 controls the operation of the entire database service providing apparatus.

[0044] Memory 152 provides a working area used when CPU 151 executes various processes. Of the components constituting event notification service providing device 150, each component except for CPU 151 and memory 152 may be configured as hardware or software.

[0045] Examples of the event notification service providing device 150 include a PC, a server, and a virtual server on the cloud. In this embodiment, a general stream service is assumed as the event notification service. However, any type of service may be used as long as the service can notify data updates as events.

[0046] Next, the history creation service providing device 120 will be described.

[0047] After receiving the event notified from the event notification service providing device 150, the history creation service providing device 120 creates a data item corresponding to the event. Then, the history creation service providing device 120 transmits a request to the database service providing device 140 to add the created data item to the license history table.

[0048] The CPU 121 controls the overall operation of the history creation service providing device. The memory 122 provides a working area that the CPU 121 uses when executing various processes.

[0049] Of the components constituting history creation service providing device 120, each component except for CPU 121 and memory 122 may be configured as hardware or software. Examples of history creation service providing device 120 include a PC, a server, and a virtual server on the cloud.

[0050] The operation of each unit of the registration-service providing device 100 shown in FIG. 1, excluding the CPU 101 and memory 102, will be described with reference to the flow charts of FIG. 2, FIG. 3, FIG. 4, and FIG.

[0051] Similarly, the operation of each unit constituting the history acquisition service providing device 110 shown in FIG. 1, excluding the CPU 111 and memory 112, will be described with reference to the flow charts of FIG. 2, FIG. 3, FIG. 4, and FIG.

[0052] Similarly, the operation of each unit constituting history creation service providing device 120 shown in FIG. 1, excluding CPU 121 and memory 122, will be described with reference to the flow charts of FIGS.

[0053] Similarly, the operation of each unit of the terminal device 130 shown in FIG. 1, excluding the CPU 131 and memory 132, will be described with reference to the flow charts of FIGS.

[0054] Fig. 2 is a flow diagram when adding a license. First, on the user list screen displayed on the Web browser 133, the operator of the terminal device 130 selects a user (assumed to be User A) to whom a license is to be added, and presses the license information display button (S201). Fig. 7A is a display example of the user list screen. The user list screen displays a list of users whose licenses are to be managed by the operator.

[0055] As a result of pressing the button, a license information screen is displayed on the Web browser 133. Fig. 7B is an example of the license information screen displayed before a license is added. The license information screen displays a list of the current number of licenses for each service assigned to the user.

[0056] When the Add button is pressed on the license information screen (S202), a license addition screen is displayed. Fig. 8A is an example of the license addition screen. On the license addition screen, it is possible to select the name of the service to be added, specify the contract ID at the time of adding the license, and the initial number of licenses to be initially assigned. When the Add button is pressed on the license addition screen (S203), the web browser 133 transmits a license addition request to the registration service providing device 100 (S204).

[0057] When the registration-service providing device 100 receives a license addition request, the update time acquisition unit 103 acquires the current time (S205).

[0058] Thereafter, the data update unit 104 requests the database service providing device 140 to add data items to the license management table (S206). The data items to be added include the user ID, service ID, contract ID, and number of licenses received from the terminal device 130, and the current time acquired by the update time acquisition unit 103.

[0059] When the database service providing device 140 receives the addition request and adds the data item to the license management table in FIG. 9A, the event notification service providing device 150 transmits an addition event to the history creation service providing device 120 (S207).

[0060] The history creation service providing device 120, which has received the addition event, performs a history update process (S208).

[0061] Fig. 3 is a flow diagram when changing a license. First, on the user list screen displayed on the Web browser 133, the operator of the terminal device selects a user (assumed to be User A) to whom a license is to be added, and presses the license information display button (S301). Fig. 7A is a display example of the user list screen. The user list screen displays a list of users whose licenses are to be managed by the operator.

[0062] As a result of pressing the button, a license information screen is displayed on the Web browser 133. Fig. 7C shows an example of the license information screen displayed when a license for the service has already been assigned to the user.

[0063] When the Change button is pressed on the license information screen (S302), a license change screen is displayed. Fig. 8B is an example of the license change screen. On the license change screen, the name of the service for which the number of licenses is to be changed is displayed, and the contract ID at the time of license change and the number of licenses after the change can be specified. When the Change button is pressed on the license change screen (S303), the Web browser 133 transmits a license change request to the registration service providing device 100 (S304).

[0064] When the registration-service providing device 100 receives the license change request, the update time acquisition unit 103 acquires the current time (S305).

[0065] Thereafter, the data update unit 104 requests the database service providing device 140 to change the data items in the license management table (S306). The data items to be changed include the user ID, service ID, contract ID, and number of licenses received from the terminal device 130, and the current time acquired by the update time acquisition unit 103.

[0066] When the database service providing device 140 that has received the change request updates the data items in the license management table of FIG. 9A, the event notification service providing device 150 transmits a change event to the history creation service providing device 120 (S307).

[0067] The history creation service providing device 120 that receives the change event performs a history update process (S308).

[0068] FIG. 4 is a flow diagram showing a process for deleting a license.

[0069] First, on the user list screen displayed on the Web browser 133, the operator of the terminal device selects a user (assumed to be User A) to whom a license is to be added, and presses the license information display button (S401). FIG. 7A is an example of the user list screen. The user list screen displays a list of users whose licenses the operator manages. As a result of pressing the button, a license information screen is displayed on the Web browser 133. FIG. 7C is an example of the license information screen displayed when a service license has already been assigned to the user.

[0070] When the Delete button is pressed on the license information screen (S402), a license deletion screen is displayed. Fig. 8C is an example of the license deletion screen. On the license deletion screen, the name of the service for which the license is to be deleted, the current number of licenses, and the contract ID at the time of license deletion can be specified. When the Delete button is pressed on the license deletion screen (S403), the Web browser 133 transmits a license deletion request to the registration service providing device 100 (S404).

[0071] When the registration service providing device 100 receives the license deletion request, the data update unit 104 requests the database service providing device 140 to delete data items from the license management table (S405). The data items to be deleted include the user ID and service ID received from the terminal device 130.

[0072] When the database service providing device 140 that has received the deletion request deletes the data item in the license management table of FIG. 9A, the event notification service providing device 150 transmits a deletion event to the history creation service providing device 120 (S406).

[0073] The history creation service providing device 120 that receives the deletion event performs a history update process (S407).

[0074] FIG. 5 is a flow diagram for acquiring a license history.

[0075] First, the operator of the terminal device selects a user (assumed to be User A) whose license history is to be obtained on the user list screen displayed on the Web browser 133, and presses the history file output button (S501).

[0076] As a result of pressing the button, a history file output request is sent from the Web browser 133 to the history acquisition service providing device 110 (S502).

[0077] The history list acquisition unit 114 in the history acquisition service providing device 110 that has received the history file output request acquires a list of data items in the license history table from the database service providing device 140 (S504).

[0078] Thereafter, history generation section 113 refers to the data item list acquired by history list acquisition section 114, sorts it by the value of event occurrence time 916, and then generates it as a history file and transmits it to terminal device 130 (S505).

[0079] FIG. 10 is an example of a history file transmitted when the values ​​in FIG. 9B are set in the license history table, written in CSV format.

[0080] In the history file of Fig. 10, the values ​​of the user ID, service ID, contract ID, number of differential licenses, and event occurrence time are linked with commas and stored in the order of the event occurrence time. Note that in this embodiment, since it is assumed that the accuracy of the event occurrence time value stored in the history file is required to the second digit, milliseconds are truncated in the history file of Fig. 10.

[0081] Next, the history update processes S208, S308, and S407 described in the flow diagrams of FIGS. 4, 5, and 6 will be described in detail with reference to the flow diagram of FIG.

[0082] First, the event receiving unit 123 of the history creation service providing device 120 receives an update event of the license management table from the event notification service providing device 150 (S601). Then, the event correction condition determination unit 124 acquires the event type of the update event (S603). If the event type is a deletion event (REMOVE), it is determined that correction is necessary, and the event occurrence time correction unit 125 acquires the value of the update date and time attribute included in the pre-update data described in the event (S604). FIG. 11D is an example of a deletion event. In this example, the acquired value of the update date and time attribute is "2020-12-01T15:30:30.300Z". Next, the event occurrence time correction unit 125 adds a predetermined correction value to the acquired value of the update date and time attribute to obtain a correction candidate value (S605).

[0083] In this embodiment, the correction value is set to the minimum of 1 millisecond, resulting in a correction value of "2020-12-01T15:30:30.301Z".

[0084] The correction value may be any value that is equal to or greater than 0 and does not exceed the error requirement of the event occurrence time in the history file of Fig. 10. For example, if the specification allows for a maximum error of 1 minute, the correction value may be set in the range of 1 millisecond ≦ correction value ≦ 60000 milliseconds. Next, the event occurrence time correction unit 125 compares the value of the notification time described in the event with the correction candidate value (S606).

[0085] If the correction candidate value is equal to or greater than the notification time value (Yes in S607), the event occurrence time correction unit 125 creates a data item to be added to the license history table, and then sets the correction candidate value to the event occurrence time attribute of the data item. Also, the difference license count attribute is set to a value obtained by subtracting the current number of licenses included in the pre-update data of the event from 0. The event ID, user ID, and service ID attributes are set to the values ​​included in the pre-update data of the event (S608).

[0086] Thereafter, the history update unit 126 transmits a request to add the data item to the license history table to the database service providing device 140 (S609). Upon receiving the addition request, the database service providing device 140 adds the data item to the license history table (S613).

[0087] If the correction candidate value is less than the notification time value (No in S607), the event occurrence time correction unit 125 creates a data item to be added to the license history table, and then sets the event occurrence time attribute of the data item to the event notification time. Note that this setting is for bringing the event occurrence time closer to the actual value while maintaining the order of the events, and if only the order is important, the correction candidate value may be set as in S608. Also, as in S608, the difference license number attribute, event ID, user ID, and service ID attributes are set in the data item (S612). Thereafter, the processes of S609 and S613 already described are performed.

[0088] If the update event type is other than a deletion event (addition or update event) in S603, it is determined that correction is not necessary, and the event occurrence time correction unit 125 obtains the value of the update date and time attribute from the updated data of the event (S610).

[0089] Thereafter, the event occurrence time correction unit 125 creates a data item to be added to the history, and sets the acquired value of the update date and time attribute to the event occurrence time attribute of the data item. Furthermore, in the case of an addition event, the difference license number attribute is set to the value of the current license number attribute of the post-update data of the event. In the case of an update event, the difference license number attribute is set to a value obtained by subtracting the current license number attribute of the pre-update data from the current license number attribute of the post-update data of the event. Furthermore, the event ID, user ID, and service ID attributes are set to values ​​contained in the post-update data of the event (S611). Thereafter, the processes of S609 and S613 already described are performed.

[0090] Second embodiment Next, a second embodiment of the present invention will be described with reference to the block diagram of FIG.

[0091] 12, a valid time acquisition unit 1201 that acquires the valid range of the event occurrence time that is output to the history file described in the first embodiment is added to the configuration of history creation service providing device 120 in FIG.

[0092] This enables the event occurrence time correction unit 125 to determine the correction value of S605 described in FIG. 6 of the first embodiment based on the significant digits of the event occurrence time in the history file created in S505 of FIG. 5.

[0093] As a result, the event occurrence time of a deleted event that is output to the history file can be set to a value that is different from the event occurrence time of the previous event.

[0094] Fig. 13 is an example of a license management table managed by the database service providing apparatus 140 of this embodiment. A valid time attribute 1301, which is the valid range of the event occurrence time output to the history file, is added to the attributes described in Fig. 9, and the minimum valid time value is set to 1 (sec). Note that in this embodiment, it is assumed that the value of the valid time attribute is set when a data item is added to the license management table (S206). However, this may be any time before the data item is deleted from the license management table.

[0095] Fig. 14 is an example of a description of a delete event when the validity time attribute 1301 has been added to the license management table. A validity time attribute value 1401 has been added to the description of the delete event described in Fig. 11D.

[0096] Fig. 15 is an example of the output of a history file generated in this embodiment. Unlike the event occurrence time of the deletion event explained in Fig. 10, as shown in 1501, a value that is different from the event occurrence time of the change event in the previous line is set.

[0097] Next, the operation of this embodiment will be described with reference to the flow chart of FIG.

[0098] In the flow diagram of Fig. 16, the process of S1601 is added after the process of S604 in Fig. 6. In S1601, the valid time acquisition unit 1201 sets the value of the valid time attribute from the pre-update data of the deleted event, and sets it as the correction value used by the event occurrence time correction unit 125. The other processes are the same as those in Fig. 6, so the explanation will be omitted.

[0099] (Third embodiment) When deleting a data item from a table managed by a database service, a logical deletion process may be performed in which an attribute indicating that the data item has been deleted is set when a deletion request is received, and then the data items are deleted in bulk later using an automatic deletion function.

[0100] This is done when there are many processes to be performed simultaneously with the deletion of a data item, or when there is a possibility that the deleted data item may be referenced by another process.

[0101] One way to handle this is to use a special attribute called TTL (Time To Live), which will automatically delete a data item once it has reached the time set in the TTL.

[0102] When logical deletion processing is performed in the first embodiment, the event occurrence time of the deletion event added to the license history may be significantly different from the time when the terminal device 130 performed the license deletion processing.

[0103] In order to solve this problem, a third embodiment of the present invention will be described with reference to the block diagram of FIG.

[0104] In FIG. 17, a deletion method acquisition unit 1701 for determining whether a data item has been automatically deleted is added to the configuration of history creation service providing device 120 in FIG.

[0105] This makes it possible to determine whether or not a deleted event notified by event notification service providing device 150 described in FIG. 1 of the first embodiment has been automatically deleted by database service providing device 140.

[0106] In the case of automatic deletion, when correcting the event occurrence time of the deletion event to be added to the license history, it is possible to prevent a large discrepancy in the event occurrence time by using the value of the update time attribute of the pre-update data contained in the event.

[0107] Fig. 18 shows an example of a license management table in this embodiment managed by the database service providing device 140. In addition to the attributes described in Fig. 9, a deletion flag attribute 1801 indicating that the license has been logically deleted and a TTL attribute are added.

[0108] Fig. 19 shows an example of a description of a deletion event notified by event notification service providing device 150 when a data item is deleted from the license management table based on the TTL attribute. In addition to the attributes in Fig. 11D, the deletion event further includes a deletion flag, a TTL attribute, and a deletion executor 1901 indicating that the database service has automatically deleted the data item based on the TTL attribute.

[0109] Next, the operation of this embodiment will be described with reference to the flow chart of FIG.

[0110] In the flow diagram of FIG. 21, the processes of S2101 and S2102 are added after the process of S605 in FIG.

[0111] In S2101, the deletion method acquisition unit 1701 acquires information indicating whether the database service automatically deleted the data item by referring to the deletion event shown in FIG. 19. In a typical stream service, if the value of "deleter" is "database service", it can be determined that the deletion was due to TTL.

[0112] If the deletion was performed automatically by TTL (Yes in S2102), proceed to the processing of S608. Figure 20 is an example of the output of a history file when a data item is automatically deleted. The value of the update date and time attribute of the data before the update is used, not the notification time included in the deletion event in Figure 19, and is set to 2001 in Figure 20.

[0113] If the deletion was not performed automatically (No in S2102), the process proceeds to S606. The other processes are the same as those in FIG. 6, so the description will be omitted.

[0114] (Other embodiments) The present invention can also be realized by a process in which a program for implementing one or more of the functions of the above-described embodiments is supplied to a system or device via a network or a storage medium, and one or more processors in a computer of the system or device read and execute the program. The present invention can also be realized by a circuit (e.g., ASIC) that implements one or more of the functions.

Claims

1. 1. A history creation service providing device that, when a data update process of a database is performed in response to a request from a terminal device, receives an update event of the data update process and creates an update history based on the update event, an acquisition means for acquiring a notification time of the update event and a time of an update process of the data before the update event occurs; a generation means for generating a correction candidate value based on a time of a data update process before the update event occurs and a predetermined correction value when the type of the update event is data deletion; a setting means for setting the correction candidate value to an event occurrence time attribute when the correction candidate value is greater than or equal to the value of the notification time of the update event, and for setting the notification time of the update event to the event occurrence time attribute when the correction candidate value is not greater than or equal to the value of the notification time of the update event.

2. The method further includes a determination unit for determining whether an update event of the data update process is a delete event due to automatic deletion, The history creation service providing device according to claim 1, characterized in that when the judgment means judges that the event is a deletion event due to automatic deletion, the generation means uses the time of the data update process before the update event occurred when generating the correction candidate value.

3. 1. A method for providing a history creation service, comprising: receiving an update event of a data update process of a database in response to a request from a terminal device; and creating an update history based on the update event, the method comprising: an acquisition step in which an acquisition means acquires a notification time of the update event and a time of an update process of the data before the update event occurs; a generation step of generating a correction candidate value based on a time of a data update process before the update event occurs and a predetermined correction value when the type of the update event is data deletion; A method for providing a history creation service, comprising: a setting step in which, when the correction candidate value is greater than or equal to the value of the notification time of the update event, an update means sets the correction candidate value to an event occurrence time attribute, and when the correction candidate value is not greater than or equal to the value of the notification time of the update event, sets the notification time of the update event to the event occurrence time attribute.

4. Computer, 1. A history creation service providing device that, when a data update process of a database is performed in response to a request from a terminal device, receives an update event of the data update process and creates an update history based on the update event, an acquisition means for acquiring a notification time of the update event and a time of an update process of the data before the update event occurs; a generation means for generating a correction candidate value based on a time of a data update process before the update event occurs and a predetermined correction value when the type of the update event is data deletion; a setting means for setting the correction candidate value to an event occurrence time attribute when the correction candidate value is equal to or greater than the value of the notification time of the update event, and for setting the notification time of the update event to the event occurrence time attribute when the correction candidate value is not equal to or greater than the value of the notification time of the update event.

Images