JP7499313B2 - Update control device, update control method, and update control program - Google Patents

Description

The present invention relates to an update control device, an update control method, and an update control program.

Nowadays, for example, companies have introduced workflow systems that computerize (digitize) the various business procedures such as applications and approvals that are carried out within the company. With regard to this workflow system, Patent Document 1 (JP Patent Publication No. 2003-108720) discloses a workflow support system.

In the workflow support system disclosed in Patent Document 1, on a preset extraction date, data on patent applications that meet preset extraction conditions is read from the domestic patent master on the mainframe to the examination request DB on the server. Then, from then on, the data in the examination request DB (data as of the extraction date) is used exclusively to consider whether or not an examination request is required for each application, and the results of this consideration, as well as any errors discovered or corrected during the consideration process, are also stored exclusively in the examination request DB. At a specified time, the data in this examination request DB is written back to the domestic patent master. Between reading and writing, the data in the domestic patent master is updated as needed. This makes it possible to maintain the stability of data in each business while ensuring the reliability of data in databases used for various business operations.

JP 2003-108720 A

However, in conventional workflow systems, the entered data is immediately treated as valid data, which can lead to the inconvenience of the database being updated with incorrect data.

The present invention has been made in consideration of the above-mentioned problems, and aims to provide an update control device, an update control method, and an update control program that enable a database to be updated with accurate data.

In order to solve the above-mentioned problems and achieve the object, an update control device according to the present invention has an approval necessity determination section which determines whether or not a real database in which data for which an update is requested is stored is a database that requires the approval of an approver when updating, based on approval necessity information set in the real database for which an update is requested, and a storage control section which, when a determination result indicating that the real database in which the data for which an update is requested is stored is a database that requires the approval of an approver when updating, stores data to be stored in the real database by the update request in a voucher database that is a database different from the real database, and, when the approval of the approver is not obtained, rejects the update of the real database using the data stored in the voucher database, and, when the approval of the approver is obtained, migrates and stores the data stored in the voucher database to the real database. When the approval necessity determination section detects a category corresponding to the data for which an update is requested in an application type category master in which approval necessity information is stored which is information that associates an application type, which is a type of data for which an update is requested, with a category that requires the approval of an approver when updating among categories indicating the classification of data stored in the real database, determines that the real database for which an update is requested is a database that requires the approval of an approver when updating.

In order to solve the above-mentioned problems and achieve the object, an update control method according to the present invention includes an approval necessity determination step in which an approval necessity determination unit determines whether or not a real database in which data requested to be updated is stored is a database that requires approval from an approver when updating, based on approval necessity information set in the real database requested to be updated; and a storage control unit, when a determination result indicating that the real database in which the data requested to be updated is stored is a database that requires approval from an approver when updating, which is a determination result in the approval necessity determination step, stores data to be stored in the real database in response to the update request in a voucher database that is a database different from the real database, and stores the data ... the voucher database. If approval is not obtained, updating of the real database with the data stored in the voucher database is rejected, and if approval from the approver is obtained, the data stored in the voucher database is transferred to and stored in the real database.In the approval necessity determination step, if a category corresponding to the data requested to be updated is detected in the application type category master which stores approval necessity information which is information that associates the application type, which is the type of data being applied for update, with categories which indicate the classification of data stored in the real database and which require the approver's approval for updating, it is determined that the real database requested to be updated is a database which requires the approver's approval when updated.

In order to solve the above-mentioned problems and achieve the object, an update control program according to the present invention includes an approval necessity determination unit that determines whether or not a real database in which data requested to be updated is stored is a database that requires approval from an approver when updating, based on approval necessity information set in the real database requested to be updated, and when a determination result indicating that the real database in which the data requested to be updated is stored is a database that requires approval from an approver when updating, which is a determination result of the approval necessity determination unit, stores data to be stored in the real database in response to the update request in a voucher database that is a database different from the real database, and when approval from the approver is not obtained, stores the data in the real database in response to the update request in a voucher database that is a database different from the real database. An update of the real database using the data stored in the ticket database is rejected, and if the approver's approval is obtained, the computer is made to function as a storage control unit that transfers and stores the data stored in the ticket database in the real database, and when the computer is made to function as an approval necessity determination unit, if a category corresponding to the data requested to be updated is detected in an application type category master that stores approval necessity information, which is information that associates an application type, which is the type of data being applied for update, with a category that indicates the classification of data stored in the real database and requires the approver's approval for updating, the computer is made to function as determining that the real database requested to be updated is a database that requires the approver's approval when updated.

The present invention has the advantage of being able to update the database with accurate data.

FIG. 1 is a diagram showing a system configuration of an update control system according to an embodiment. FIG. 2 is a diagram showing an update form of a database in an update control system that is a comparative example to the update control system according to the embodiment. FIG. 3 is a diagram showing an outline of the system operation in the update control system according to the embodiment. FIG. 4 is a diagram for explaining settings of approvers in the administrator setting master that is referred to when updating the real table. FIG. 5 is a diagram showing how various information about departments or users to be registered in the administrator setting master is obtained from other masters and registered in the administrator setting master. FIG. 6 is a diagram for explaining the setting of tables requiring approval in the application type category allocation master that is referred to when updating the real table. FIG. 7 is a diagram showing how application types and categories (tables) are associated and registered in the application type-category allocation master. FIG. 8 is a flow chart for explaining the updating operation of the real table in the update control device according to the embodiment. FIG. 9 shows the update operation for the real table when an address registration application is made by an employee of the Tokyo Personnel Department of the Tokyo head office. FIG. 10 is a diagram showing a provisional registration operation in the form table when an address registration application is made by an employee of the Kansai General Affairs Department of the Kansai branch office. FIG. 11 is a diagram showing the update operation for the real table when an application for registration of previous job information is made by an employee of the Kansai General Affairs Department of the Kansai branch office. Figure 12 is a diagram summarizing the operation of the update control device when a request for new registration, modification, or deletion of data is made by an administrator who does not require the approval of an approver for the update, or when the category of the requested data is not registered in the application type category allocation master. Figure 13 is a diagram summarizing the operation of the update control device when a new registration, modification, or deletion of data is requested by a user who requires the approval of an approver for an update, or when the category of the requested data is registered in the application type category allocation master.

The following describes in detail an update control system according to an embodiment of the present invention with reference to the drawings. Note that the present invention is not limited to this embodiment. Note that the concept of "update" is a broad concept that includes all actions that change the data structure of a database, such as data registration, modification, addition, deletion, etc.

(System configuration)
Fig. 1 is a diagram showing a system configuration of an update control system according to an embodiment. As shown in Fig. 1, the update control system is configured by connecting an update control device 1, an application terminal device 9, and an approval terminal device 10 to each other via a network 8. As the network 8, for example, a wide area network such as the Internet, or a private network such as a LAN (Local Area Network) can be used.

The application terminal device 9 is a terminal device operated by a user who applies for a database (table) update. The approval terminal device 10 is a terminal device of an approver who approves the table update applied for from the application terminal device 9. The update control device 1 accepts a table update application from the terminal device 9, and when the update is approved by the approver via the approval terminal device 10, it updates the database of the applied data.

As the update control device 1, the application terminal device 9, and the approval terminal device 10, in addition to a desktop personal computer device, a notebook personal computer device, or a tablet personal computer device can be used. Also, as the update control device 1, the application terminal device 9, and the approval terminal device 10, a PDA (Personal Digital Assistant) device or a portable information processing device such as a smartphone can be used.

(Hardware configuration of update control device)
As shown in FIG. 1, the update control device 1 includes a storage unit 2, a control unit 3, a communication interface unit 4, and an input/output interface unit 5.

An input device 6 and an output device 7 are connected to the input/output interface unit 5. The output device 7 can be a display unit such as a monitor device (including a home television).

As the input device 6, a keyboard device, a mouse device, a microphone device, or a monitor device that cooperates with the mouse device to realize a pointing device function can be used.

The storage unit 2 may be, for example, a storage device such as a ROM (Read Only Memory), a RAM (Random Access Memory), a HDD (Hard Disk Drive), or a SSD (Solid State Drive). The storage unit 2 stores an administrator setting master 11, an application type category allocation master 12, an organization master 13, a department master 14, a user master 15, an actual table 16, an invoice table 17, and an application type group master 18. The storage unit 2 also stores an application type master 19, a code master 20, an employee information category master 21, and an update control program.

The administrator setting master 11 stores users or departments that have the authority to approve updates to the database of requested data. The application type category allocation master 12 stores the application type of the update and the data type (category) for which the update requires the approval of an approver. The organization master 13 stores organization codes and organization names, etc. The department master 14 stores department codes, organization codes of the organizations to which the departments belong, department names, etc. The user master 15 stores user identification numbers (user IDs), passwords, user names, etc.

The application category group master 18 stores the application category group ID and application category group name, etc. The application category master 19 stores the application category code, application category name, and application category group code. The code master 20 stores the category, code value, and table name. The employee information category master 21 stores the category group ID, category ID, category name, display flag, display order, etc.

The real table 16 is an example of a real database, and is a storage area for registered data. The real table 16 has storage areas (tables) for each category, such as a table that stores data in the "Basic" category, a table that stores data in the "Address" category, a table that stores data in the "Family" category, etc. The submitted data is stored in the table for the corresponding category.

The invoicing table 17 is an example of an invoicing database, and is a storage area where data before updating the actual table 16 is temporarily stored. The update control device 1 temporarily stores the applied data in this invoicing table 17, and when approval is obtained from the approver, it transfers the data from the invoicing table 17 to the actual table 16 and changes (updates) the data structure of the actual table 16. This makes it possible to update the actual table 16 with only the accurate data that has been approved by the approver. Note that the invoicing table 17 is also made up of tables of multiple categories, just like the actual table 16.

(Functional configuration of update control device)
Next, the control unit 3 of the update control device 1 functions as a master setting unit 31, an acquisition unit 32, an authority discrimination unit 33, an approval necessity discrimination unit 34, a memory control unit 35, a display control unit 36, and a communication control unit 37 by executing the update control program stored in the memory unit 2.

The master setting unit 31 sets various data for the administrator setting master 11 and the application type category allocation master 12, etc. The acquisition unit 32 acquires data, etc., applied for by the applicant via the application terminal device 9. The authority determination unit 33 determines whether the applicant who applied for the data has the authority to update the actual table 16. The approval necessity determination unit 34 determines whether the table of the category for which an update is being applied is a table that requires the approval of an approver for the update.

The storage control unit 35 temporarily stores data before approval by the approver in the invoice table 17, and stores it in the actual table 16 after approval. The display control unit 36 displays setting screens for various data for the administrator setting master 11 and the application type category allocation master 12, etc., on the output device 7. The communication control unit 37 communicates with the application terminal device 9 and the approval terminal device 10. The communication control unit 37 receives data to be updated from the application terminal device 9. The communication control unit 37 also communicates with the approval terminal device 10 to obtain approval for updating the actual table 16 with the applied data.

(Updated form of the comparative example)
Fig. 2 is a diagram showing a form of database update in an update control system that is a comparative example to the update control system of the embodiment. In Fig. 2, employee A of the Tokyo Personnel Department and employee G of the Kansai branch are both users who have the authority to update the database. As shown in Fig. 2, in the update control system that is the comparative example, if the employee had the authority to update the database, they could freely access the database and update it.

For this reason, for example, employee information and other data submitted by a person in charge at a branch office in the Kansai region (i.e. employee G, who has no authority) is registered in the database as actual data without being examined, and even if the data is incorrect, it is used as is as personnel data, which is inconvenient.

Employees themselves can review certain information (such as family or address information) from personnel notification applications, but employee information from bases such as the Kansai branch is entered either directly or by accepting a file, making it difficult for approvers to review it.

In addition, even if the data in the database was corrected, it could still be rewritten later by a user with the authority to change the data.

(System Overview of the Embodiment)
For this reason, when updating a database, the update control system according to the embodiment is designed to update the database with accurate data that has been scrutinized by an approver.

Figure 3 is a diagram showing an overview of the system operation in the update control system of the embodiment. As shown in this Figure 3, when an update to a database (table) is requested, the update control device 1 of the update control system of the embodiment refers to the administrator setting master 11 and determines whether the user who made the request has update authority for the database. It also determines whether the table that stores the data for which an update is requested is a table that requires the approval of an approver.

If the user who made the request has update authority for the database, the requested data is updated in real table 16. Also, if the table that stores the data for which an update is being requested is not a table that requires the approval of an approver, the requested data is updated in real table 16.

On the other hand, if the user who made the request does not have update authority for the database, the requested data is temporarily stored in the invoicing table 17. Also, if the table that stores the data for which an update is being requested is a table that requires the approval of an approver, the requested data is temporarily stored in the invoicing table 17.

When the update control device 1 has temporarily stored the requested data in the invoice table 17, it submits an approval request to the approval terminal device 10 for the update of the real table 16 with the requested data (corresponding to the employee information request in FIG. 3). The approver decides whether to approve or reject the update of the real table 16 with the requested data, and notifies the update control device 1 via the approval terminal device 10.

The update control device 1 transfers only the data approved via the approval terminal device 10 from the invoicing table 17 to the real table 16, and updates the real database 16. The update control device 1 discards (deletes) data that has not been approved by the approver from the invoicing table 17, and rejects (denies) the update to the real table 16. This allows the real table 16 to be updated using only the data approved by the approver.

(Administrator settings master configuration)
Next, FIG. 4 is a diagram for explaining the setting of the approver for the administrator setting master 11 that is referred to when updating the real table 16. Although it is an example, the setting for the administrator setting master 11 is performed on the Tokyo head office side shown in FIG. 4(a). The user or the user of the department registered in the administrator setting master 11 becomes a "user or the user of the department who has the authority to update the real data without the approval of the administrator. The examples of FIG. 4(a) and FIG. 4(b) are examples in which the Tokyo Personnel Department is set in the administrator setting master 11 as a "department" that has the authority to update the real data without the approval of the administrator. In this case, employees A and B of the Tokyo Personnel Department have the authority to update the real data without the approval of the administrator. In addition, the examples of FIG. 4(a) and FIG. 4(b) are examples in which employee C of the Tokyo General Affairs Department is set in the administrator setting master 11 as a "user" that has the authority to update the real data without the approval of the administrator. In this case, employee C of the Tokyo General Affairs Department has the authority to update the real data without the approval of the administrator.

That is, when an approver is specified for the administrator setting master 11 by a business operator or the like, the display control unit 36 displays the administrator setting screen shown in FIG. 4(b) on the output device 7. The business operator sets the department or user to be the approver via this administrator setting screen.

In the example of FIG. 4(b), the record in the top row indicates that a "department" with approval authority has been set. In other words, this record in the top row indicates that approval authority was set for the Tokyo Personnel Department on December 1, 2021. In addition, in the example of FIG. 4(b), the record in the bottom row indicates that a "user" with approval authority has been set. In other words, this record in the bottom row indicates that approval authority was set for "Employee C" with user ID "UserIdC". In this way, information indicating the department or user to which approval authority has been selectively granted is stored (set) in the administrator master 11.

Figure 5 is a diagram showing how various information on departments or users to be registered in the administrator setting master 11 is obtained from other masters and registered in the administrator setting master 11. As shown in this figure, when a department is designated as an approver by an employee of the Tokyo personnel department, the master setting unit 31 obtains the organization code and organization revision date and time from the organization master 13 shown in Figure 5 (a), and obtains the organization code, organization revision date and time, and department code from the department master 14 as shown in Figure 5 (b), and sets (registers) them in the administrator setting master 11 as shown in Figure 5 (c). Similarly, when a user is designated as an approver by an employee of the Tokyo personnel department, the master setting unit 31 obtains a user ID from the user master 15 as shown in Figure 5 (d), and sets (registers) them in the administrator setting master 11 as shown in Figure 5 (c).

(Application type category allocation master settings)
Next, Fig. 6 is a diagram for explaining the setting of tables requiring approval in the application type category allocation master 12 that is referred to during updating. When the business operator or the like specifies the setting of tables requiring approval in the application type category allocation master 12, the display control unit 36 displays the application type/employee information category allocation screen shown in Fig. 6(b) or 6(c) on the output device 7. The business operator performs a setting operation to associate each table (category name) requiring approval with the application type via this application type/employee information category allocation screen.

The example in FIG. 6(b) is an example in which the tables in the categories of "Basic", "Address", "Family", "Educational Background", and "Hometown" are set as tables requiring approval for an application type of "Employee Attributes" with an application type code of "CD1010". The example in FIG. 6(c) is an example in which the tables in different categories are set as tables requiring approval for an application type of "Employee Attributes" with an application type code of "CD1010". In other words, the example in FIG. 6(c) is an example in which the tables in the categories of "Basic", "Family", "Social Insurance", and "Tax Table Classification" are set as tables requiring approval for an application type of "Employee Attributes" with an application type code of "CD1020".

Figure 6 (a) shows an example of an approval route for each application type. That is, approval route A shown by a dotted line in Figure 6 (a) shows the approval route for employee attributes with application type code "CD1010". For example, updates to real table 16 using employee attribute data by employee F in the Yokohama General Affairs Department of the Yokohama branch and employee G in the Kansai branch must receive final approval from employee A in the Tokyo Personnel Department.

Also, approval route B shown by a solid line in FIG. 6(a) indicates an approval route related to employee insurance with application type code "CD1020". For example, updates to real table 16 with employee insurance-related data by employee E in the Yokohama General Affairs Department of the Yokohama branch and employee G in the Kansai branch must first be approved by employee D in the Tokyo General Affairs Department, and then must receive final approval from employee C.

Figure 7 is a diagram showing how application types and categories (tables) are associated and registered in the application type category allocation master 12. The master setting unit 31 refers to the application type group master 18 shown in Figure 7 (a) and the application type master 19 shown in Figure 7 (b) to obtain an application type code such as "CD1010", and sets (registers) it in the application type category allocation master 12 as shown in Figure 7 (c).

The master setting unit 31 also obtains the table name by referencing the code master 20 shown in FIG. 7(d), and obtains the category group ID, category ID, and display order by referencing the employee information category master 21 shown in FIG. 7(e), and sets (registers) them in the application type category allocation master 12 as shown in FIG. 7(c). This allows the application type and category (table) to be associated and registered in the application type category allocation master 12.

(Table update operation)
Next, the table update operation in the update control device 1 will be described with reference to the flowchart in Fig. 8. The control unit 3 executes each process shown in the flowchart in Fig. 8 based on the update control program stored in the storage unit 2. First, in step S1, the communication control unit 37 receives data for an update application transmitted from the application terminal device 9 via the network 8 via the communication interface unit 4, and the acquisition unit 32 acquires the received data.

The acquired data is then assigned the department information of the user making the application, the user ID, and an application type code indicating the application type. Therefore, in step S2, the authority determination unit 33 refers to the administrator setting master 11 shown in FIG. 5(c) based on the user's department information and user ID attached to the data acquired in step S1. Then, it is determined whether at least one of the user's department information or user ID attached to the acquired data is registered in the administrator setting master 11.

If at least one of the department information or user ID of the user attached to the acquired data is registered in the administrator setting master 11 (step S2: Yes), this indicates that the user currently making the application has update authority. In this case, the process proceeds to step S3, and the storage control unit 35 updates the actual table 16 corresponding to the category of the data being applied for with the applied data.

On the other hand, if at least one of the department information or user ID of the user attached to the acquired data is not registered in the administrator setting master 11 (step S2: No), this indicates that the user currently making the application does not have update authority. In this case, the process proceeds to step S4, and the storage control unit 35 temporarily stores the applied data in the invoicing table 17 corresponding to the category of the data being applied for (provisional registration).

When the applied data is stored in the invoice table 17, the communication control unit 37 communicates with the approval terminal device 10 and requests the approver to approve the update of the real table 16 with the currently applied data. In step S5, the storage control unit 35 determines whether the update of the real table 16 has been approved by the approver.

If the update is approved by the approver (step S5; Yes), in step S3, the storage control unit 35 transfers the data currently temporarily stored in the voucher table 17 to the actual table 16 corresponding to the category of the data being applied for, and updates it. This allows the data approved by the approver to be updated in the actual table 16, so that the actual table 16 can be updated with accurate data.

On the other hand, if the update is rejected by the approver (step S5; No), rejection processing is performed in step S6. In this rejection processing, for example, the memory control unit 35 erases the data temporarily stored in the application table 17, and the communication control unit 37 sends an error message to the application terminal device 9 of the user who made the application indicating that the update has not been approved and has been rejected. This makes it possible to prevent the inconvenience of updating the real table 16 with data not approved by the approver, and allows the real table 16 to be updated with accurate data.

On the other hand, in step S2, the approval necessity determination unit 34 determines whether the table in which the currently requested data is to be updated is data for a table that can be updated even by an unauthorized user.

That is, in the case of the update control device 1 according to the embodiment, the actual table 16 of the same category as the category of the applied data is updated by the applied data. Therefore, the approval necessity determination unit 34 determines whether or not the category of the applied data is registered in the application type category allocation master 12 shown in FIG. 7(c).

If the category of the requested data is not registered in the application type category allocation master 12 (step S2: Yes), this means that the actual table 16 that is being updated with the requested data does not require approval from an approver to update.

Therefore, if the category of the applied data is not registered in the application type category allocation master 12, the memory control unit 35 updates the actual table 16 of the corresponding category with the applied data in step S3.

On the other hand, if the category of the requested data is registered in the application type category allocation master 12 (step S2: No), this means that the actual table 16 that is to be updated with the requested data requires the approval of an approver in order to be updated. Therefore, in step S4, the storage control unit 35 temporarily stores the requested data in the invoicing table 17 that corresponds to the category of the requested data (provisional registration).

Note that tables and categories have different meanings, but in the update control device 1 of the embodiment, when registering employee information, attributes are input as categories, and since 1 category = 1 table, the explanation is given in the sense of table = category.

When the applied data is stored in the invoicing table 17, the communication control unit 37 communicates with the approval terminal device 10 and requests the approver to approve the update of the real table 16 with the currently applied data. In step S5, the storage control unit 35 determines whether the update has been approved by the approver. If the update has been approved by the approver (step S5; Yes), in step S3, the storage control unit 35 transfers the data currently temporarily stored in the invoicing table 17 to the real table 16 corresponding to the category of the applied data, and updates the real table 16. This allows the real table 16 to be updated with the data approved by the approver, so that the real table 16 can be updated with accurate data.

On the other hand, if the update is rejected by the approver (step S5; No), rejection processing is performed in step S6. In this rejection processing, for example, the memory control unit 35 erases the data temporarily stored in the application table 17, and the communication control unit 37 sends an error message to the application terminal device 9 of the user who made the application indicating that the update has not been approved and has been rejected. This makes it possible to prevent the inconvenience of updating the real table 16 with data that has not been approved by the approver, and allows the real table 16 to be updated with only accurate data.

(Examples of updates)
Fig. 9 shows an example in which an address registration application is made by employee A of the Tokyo personnel department of the Tokyo head office. The Tokyo personnel department of the Tokyo head office shown in Fig. 9(a) is set in the administrator setting master 11 as a department that performs approval, as explained with reference to Fig. 4. Therefore, employee A of the Tokyo personnel department of the Tokyo head office has authority as an approver. Therefore, when employee A applies for address registration via the employee information management screen as shown in Fig. 9(b), the applied address data is registered in the real table 16 of the address category without obtaining approval from another approver.

In contrast, FIG. 10 shows an example in which an address registration application is made by employee G of the Kansai General Affairs Department of the Kansai Branch. Employee G of the Kansai General Affairs Department of the Kansai Branch shown in FIG. 10(a) is not set as an administrator in the administrator setting master 11, as explained using FIG. 4. Therefore, the approval necessity determination unit 34 determines whether the "Address" category of the data applied for via the employee information management screen as shown in FIG. 10(b) is registered in the application type category allocation master 12 shown in FIG. 7(c).

If the address category of the applied data is registered in the application type category allocation master 12 shown in FIG. 7(c), the real table 16 that updates the address category data requires the approval of an approver to update. For this reason, the storage control unit 35 temporarily stores the address data applied for by employee G in the document issue table 17 of the address category, as shown in FIG. 10(c). After approval by the approver, the address data stored in this document issue table 17 is transferred to the real table 16 of the address category, and the real table 16 is updated.

Figure 11 shows an example where an application for registration of previous job information is made by employee G in the Kansai General Affairs Department of the Kansai Branch. Employee G in the Kansai General Affairs Department of the Kansai Branch shown in Figure 11 (a) is not set as an administrator in the administrator setting master 11, as explained using Figure 4. Therefore, the approval necessity determination unit 34 determines whether the "previous job information" category of the data applied for via the employee information management screen as shown in Figure 11 (b) is registered in the application type category allocation master 12 shown in Figure 7 (c).

If the category of previous job information of the applied data is not registered in the application type category allocation master 12 shown in FIG. 7(c), the real table 16 that updates the data in the previous job information category does not require the approval of an approver to update. Therefore, as shown in FIG. 11(c), the memory control unit 35 updates the real table 16 for the previous job information category with the data of previous job information applied for by employee G.

(Operation when application by administrator or category is not registered)
12 is a diagram summarizing the operation of the update control device 1 in the case where a manager who does not require the approval of an approver applies for new registration, modification, and deletion of data when updating, or in the case where the category of the applied data is not registered in the application type category allocation master 12. In this case, the data applied for new registration is directly registered in the real table 16 without being temporarily stored in the voucher table 17, as shown in FIG. 12(a). The same applies to "modification," and as shown in FIG. 12(b), the data stored in the real table 16 can be freely modified. The same applies to "deletion," and as shown in FIG. 12(c), the data stored in the real table 16 can be freely deleted.

(Behavior when an application or category is registered by a user other than the administrator)
13 is a diagram summarizing the operation of the update control device 1 when a user who requires the approval of an approver for an update applies for new registration, modification, or deletion of data, or when the category of the applied data is registered in the application type category allocation master 12. In this case, the data applied for new registration is temporarily stored in the voucher table 17, as shown in Fig. 13(a). Then, when the approval of the approver is obtained, the data is transferred from the voucher table 17 to the actual table 16 and registered.

The same applies to "modification," and as shown in FIG. 13(b), the data used for the modification is temporarily stored in the document table 17. Then, when the approver's approval is obtained, the data is transferred from the document table 17 to the actual table 16, and the desired data is modified. The same applies to "deletion," and as shown in FIG. 13(c), the data used for deletion is temporarily stored in the document table 17. Then, when the approver's approval is obtained, the data is transferred from the document table 17 to the actual table 16, and the desired data is deleted.

(Effects of the embodiment)
As is clear from the above description, in the update control device 1 of the embodiment, for example, the personnel manager at a base such as the Kansai branch office and the personnel manager at the Tokyo headquarters (final approver) use the same input screen, but judges whether or not to apply for an application on the personnel and table basis. Then, until approval is obtained from the final approver, the applied data is temporarily stored in the voucher data 17, and when approval is obtained from the final approver, the applied data is transferred from the voucher data 17 to the real table 16 and the real table 16 is updated.

This allows the actual table 16 to be updated using data approved by the approver, and the database (actual table 16) can be updated with accurate data.

In addition, by processing data submitted from bases such as the Kansai branch through the workflow system, the approver can scrutinize the data, eliminating erroneous data. In addition, because application approval can be set on a table (category) basis, approval routes can be set for each employee's attribute information. This allows for a smooth process from application to approval, with performance appraisal information, for example, being approved by a supervisor, and address or family information being approved by the HR department.

[Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby making it possible to contribute to Goals 8 and 9 of the SDGs.

In addition, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, which can contribute to the achievement of SDGs Goals 12, 13, and 15.

In addition, this embodiment can contribute to strengthening control and governance, making it possible to contribute to Goal 16 of the SDGs.

[Other embodiments]
The present invention may be embodied in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.

In addition, the processing procedures, control procedures, specific names, registered data for each process, information including parameters such as search conditions, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

In addition, with regard to the update control device 1, each component shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure.

For example, the processing functions of the update control device 1, particularly the control unit 3 and each processing function performed by the control unit 3, may be realized in whole or in part by a CPU (Central Processing Unit) and a program interpreted and executed by the CPU, or may be realized as hardware using wired logic. The program is recorded on a non-transient computer-readable recording medium that contains programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the update control device 1 as necessary. That is, a computer program is recorded in a storage unit such as a ROM or HDD for working with the OS to give instructions to the CPU and perform various processes. This computer program is executed by being loaded into RAM, and works with the CPU to configure the control unit 3.

The update control program of the update control device 1 may also be stored in another server device connected to the update control device 1 via any network, and all or part of it may be downloaded as necessary.

The update control program for executing the process described in this embodiment may be stored in a non-transient computer-readable recording medium, or may be configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical Disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. Note that a "program" is not necessarily limited to a single configuration, but also includes a distributed configuration consisting of multiple modules or libraries, and a program that works in conjunction with a separate program, such as an OS, to achieve its function. Note that the specific configuration and reading procedure for reading a recording medium in the update control device 1 shown in the embodiment, as well as the installation procedure after reading, can use well-known configurations and procedures.

The memory unit 2 is a storage means such as a memory device such as RAM or ROM, a fixed disk device such as a hard disk, a flexible disk, or an optical disk, and stores various programs, tables, databases, and web page files used for various processes and providing websites.

The update control device 1 may be configured as an information processing device such as a known personal computer device or a workstation, or may be configured as an information processing device to which any peripheral device is connected. The information processing device may also be realized by implementing software (including programs or data, etc.) that realizes the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or function additions. In other words, the above-mentioned embodiments can be implemented in any combination, or the embodiments can be implemented selectively.

The present invention is useful for database data management tasks, etc.

LIST OF SYMBOLS 1 Update control device 2 Memory unit 3 Control unit 4 Communication interface unit 5 Input/output interface unit 6 Input device 7 Output device 8 Network 9 Application terminal device 10 Approval terminal device 11 Administrator setting master 12 Application type category allocation master 13 Organization master 14 Department master 15 User master 16 Actual table 17 Voucher table 18 Application type group master 19 Application type master 20 Code master 21 Employee information category master 31 Master setting unit 32 Acquisition unit 33 Authority determination unit 34 Approval necessity determination unit 35 Memory control unit 36 Display control unit 37 Communication control unit

Claims (5)

an approval necessity determination unit that determines whether or not the real database in which the data requested to be updated is stored is a database that requires approval from an approver when updating, based on approval necessity information set in the real database requested to be updated;
a storage control unit which, when a determination result from said approval necessity determination unit indicates that said real database in which the data requested to be updated is stored is a database requiring approval from an approver when updating, stores the data to be stored in said real database in response to the update request in a voucher database which is a database different from said real database, rejects the update of said real database using the data stored in the voucher database if approval from the approver is not obtained, and migrates and stores the data stored in the voucher database in said real database if approval from the approver is obtained ,
the approval necessity determination unit determines that the real database for which an update is requested is a database that requires the approval of an approver when detecting a category corresponding to the data for which an update is requested in an application category category master in which the approval necessity information is stored, the approval necessity information being information in which an application category, which is a type of data for which an update is requested, and a category that requires the approval of an approver for an update among categories indicating the classification of data stored in the real database, are associated;
An update control device comprising : an authority determination unit that determines whether or not a user who has made an update request for the real database has update authority for the real database;
said storage control unit, when a determination result obtained from said authority determination unit indicates that the user who has made an update request to said real database is a user who has update authority to said real database, or a determination result obtained from said approval necessity determination unit indicates that said real database in which said data requested to be updated is stored is a database in which approval by an approver is not required at the time of update, stores said data requested to be updated in said real database without storing it in said voucher database;
The update control device according to claim 1 . said authority determination unit determines a user who is registered in an administrator setting master and has update authority to the real database, or a user of a department who is registered in the administrator setting master and has update authority to the real database, as a user who has update authority to the real database;
The update control device according to claim 2 . an approval necessity determination step in which an approval necessity determination unit determines whether or not the real database in which the data requested to be updated is stored is a database that requires approval from an approver when updating, based on approval necessity information set in the real database requested to be updated;
a storage control step in which, when a determination result obtained in the approval necessity determination step indicates that the real database in which the data requested to be updated is stored is a database requiring approval from an approver when updating, a storage control unit stores data to be stored in the real database in response to the update request in a voucher database which is a database different from the real database, and when approval from the approver is not obtained, rejects the update of the real database using the data stored in the voucher database, and when approval from the approver is obtained, transfers and stores the data stored in the voucher database to the real database ;
In the approval necessity determination step, when a category corresponding to the data requested to be updated is detected in an application category category master in which the approval necessity information is stored, the application category being information in which an application category is a category of data requested to be updated and a category indicating a classification of data stored in the real database and requiring approval from an approver for updating, the real database requested to be updated is determined to be a database requiring approval from an approver when updated;
An update control method comprising : Computer,
an approval necessity determination unit that determines whether or not the real database in which the data requested to be updated is stored is a database that requires approval from an approver when updating, based on approval necessity information set in the real database requested to be updated;
when the determination result of said approval necessity determination section indicates that said real database in which the data requested to be updated is stored is a database requiring approval from an approver when updating, said storage control section functions as a storage control section which stores the data to be stored in said real database in response to the update request in a voucher database which is a database different from said real database, rejects the update of said real database with the data stored in the voucher database if approval from the approver is not obtained, and migrates and stores the data stored in the voucher database in said real database if approval from the approver is obtained,
When the computer is made to function as the approval necessity determination unit, when a category corresponding to the data requested to be updated is detected in an application type category master in which the approval necessity information is stored, the application type being the type of data requested to be updated, and a category indicating the classification of data stored in the real database and requiring the approval of an approver for updating, the computer is made to function to determine that the real database requested to be updated is a database requiring the approval of an approver when being updated;
An update control program comprising:

Images