JP2023110853A - 更新制御装置、更新制御方法、及び、更新制御プログラム - Google Patents

Abstract

【課題】正確なデータでデータベースの更新を可能とする。【解決手段】権限判別部は、実データベースの更新要求を行ったユーザにおける、実データベースに対する更新権限の有無を判別する。承認要否判別部は、更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された実データベースに設定されている承認要否情報に基づいて判別する。記憶制御部は、実データベースに対する更新要求を行ったユーザが、実データベースに対する更新権限の無いユーザである場合、又は、更新要求されたデータが記憶される実データベースが、更新時に承認者の承認が必要なデータベースである場合に、更新要求されているデータを、実データベースとは異なる起票データベースに記憶し、承認者の承認が得られた場合に、起票データベースに記憶したデータを、実データベースに移行して記憶する。【選択図】図８

Description

本発明は、更新制御装置、更新制御方法、及び、更新制御プログラムに関する。

今日において、例えば企業等では、社内で行われている各種申請又は稟議等の業務手続きを電子化（デジタル化）したワークフローシステムが導入されている。このワークフローシステムに関しては、特許文献１（特開２００３－１０８７２０号公報）に、ワークフロー支援システムが開示されている。

特許文献１に開示されているワークフロー支援システムは、予め設定された抽出日になると、予め設定された抽出条件に合致する特許出願のデータが、メインフレーム上の国内特実マスタからサーバ上の審査請求ＤＢに読み出される。そして、以後は、もっぱら審査請求ＤＢ内のデータ（抽出日現在のデータ）を使用して、個々の出願につき審査請求を要するか否かがを検討し、この検討結果及び検討の過程で発見又は修正されたエラーも、もっぱら審査請求ＤＢに蓄積する。この審査請求ＤＢ内のデータは、所定の時期になると、国内特実マスタに書き戻される。この読み出しから書き戻しまでの間、国内特実マスタ内のデータは随時更新される。これにより、種々の業務に使用されるデータベースのデータの信頼性を確保しつつ、個々の業務におけるデータの安定性の維持が可能となっている。

特開２００３－１０８７２０号公報

しかし、従来のワークフローシステムは、入力されたデータが即時有効なデータとして取り扱われるため、誤ったデータでデータベースが更新される不都合を生じていた。

本発明は、上述の課題に鑑みてなされたものであり、データベースを正確なデータで更新可能とした更新制御装置、更新制御方法、及び、更新制御プログラムの提供を目的とする。

上述の課題を解決し、目的を達成するために、本発明に係る更新制御装置は、更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された実データベースに設定されている承認要否情報に基づいて判別する承認要否判別部と、承認要否判別部の判別結果である、更新要求されたデータが記憶される実データベースが、更新時に承認者の承認が必要なデータベースであることを示す判別結果が得られた場合に、更新要求により実データベースに記憶するデータを、実データベースとは異なるデータベースである起票データベースに記憶し、承認者の承認が得られなかった場合は、起票データベースに記憶されたデータによる実データベースの更新は却下し、承認者の承認が得られた場合に、起票データベースに記憶したデータを、実データベースに移行して記憶する記憶制御部と、を有する。

また、上述の課題を解決し、目的を達成するために、本発明に係る更新制御方法は、承認要否判別部が、更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された実データベースに設定されている承認要否情報に基づいて判別する承認要否判別ステップと、記憶制御部が、承認要否判別ステップでの判別結果である、更新要求されたデータが記憶される実データベースが、更新時に承認者の承認が必要なデータベースであることを示す判別結果が得られた場合に、更新要求により実データベースに記憶するデータを、実データベースとは異なるデータベースである起票データベースに記憶し、承認者の承認が得られなかった場合は、起票データベースに記憶されたデータによる実データベースの更新は却下し、承認者の承認が得られた場合に、起票データベースに記憶したデータを、実データベースに移行して記憶する記憶制御ステップと、を有する。

また、上述の課題を解決し、目的を達成するために、本発明に係る更新制御プログラムは、コンピュータを、更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された前記実データベースに設定されている承認要否情報に基づいて判別する承認要否判別部と、承認要否判別部の判別結果である、更新要求されたデータが記憶される実データベースが、更新時に承認者の承認が必要なデータベースであることを示す判別結果が得られた場合に、更新要求により実データベースに記憶するデータを、実データベースとは異なるデータベースである起票データベースに記憶し、承認者の承認が得られなかった場合は、起票データベースに記憶されたデータによる実データベースの更新は却下し、承認者の承認が得られた場合に、起票データベースに記憶したデータを、実データベースに移行して記憶する記憶制御部として機能させること、を特徴とする。

本発明によれば、正確なデータでデータベースを更新できるという効果を奏する。

図１は、実施の形態の更新制御システムのシステム構成を示す図である。 図２は、実施の形態の更新制御システムに対して比較例となる更新制御システムのデータベースの更新形態を示す図である。 図３は、実施の形態の更新制御システムにおけるシステム動作の概要を示す図である。 図４は、実テーブルの更新の際に参照される管理者設定マスタに対する承認者の設定を説明するための図である。 図５は、管理者設定マスタに登録される部署又はユーザの各種情報が、他のマスタから取得されて管理者設定マスタに登録される様子を示す図である。 図６は、実テーブルの更新の際に参照される申請種別カテゴリ割付マスタに対する、承認を必要とするテーブルの設定を説明するための図である。 図７は、申請種別カテゴリ割付マスタに、申請種別及びカテゴリ（テーブル）が関連付けされて登録される様子を示す図である。 図８は、実施の形態の更新制御装置における実テーブルの更新動作を説明するためのフローチャートである。 図９は、東京本社の東京人事部の社員により、住所の登録申請が行われた場合における、実テーブルに対する更新動作を示す図である。 図１０は、関西支社の関西総務部の社員により、住所の登録申請が行われた場合における、起票テーブルに対する仮登録動作を示す図である。 図１１は、関西支社の関西総務部の社員により、前職情報の登録申請が行われた場合における、実テーブルに対する更新動作を示す図である。 図１２は、更新に承認者の承認が不要な管理者により、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタに、申請されたデータのカテゴリが登録されていない場合における、更新制御装置の動作をまとめて示す図である。 図１３は、更新に承認者の承認が必要なユーザにより、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタに、申請されたデータのカテゴリが登録されている場合における、更新制御装置の動作をまとめて示す図である。

以下、本発明を適用した実施の形態となる更新制御システムを、図面に基づいて詳細に説明する。なお、本実施形態により本発明が限定されるものではない。なお、「更新」の概念は、データの登録の他、修正、追加、削除等の、データベースのデータ構成を変更させる全ての行為を含む広義の概念である。

（システム構成）
図１は、実施の形態の更新制御システムのシステム構成を示す図である。この図１に示すように、更新制御システムは、更新制御装置１、申請端末装置９及び承認端末装置１０を、ネットワーク８を介して相互に接続して構成されている。ネットワーク８としては、例えばインターネット等の広域網、又は、ＬＡＮ（Local Area Network）等のプライベート網を用いることができる。

申請端末装置９は、データベース（テーブル）の更新の申請を行うユーザが操作する端末装置である。承認端末装置１０は、申請端末装置９から申請されたテーブルの更新の承認を行う承認者の端末装置である。更新制御装置１は、端末装置９からテーブルの更新の申請を受け付け、承認者により、承認端末装置１０を介して更新の承認が得られた際に、申請されたデータのデータベースに対する更新を行う。

更新制御装置１、申請端末装置９及び承認端末装置１０としては、デスクトップ型のパーソナルコンピュータ装置の他、ノート型のパーソナルコンピュータ装置又はタブレット型のパーソナルコンピュータ装置を用いることができる。また、更新制御装置１、申請端末装置９及び承認端末装置１０としては、ＰＤＡ（Personal Digital Assistants）装置又はスマートフォン等携帯型情報処理装置を用いることができる。

（更新制御装置のハードウェア構成）
更新制御装置１は、図１に示すように、記憶部２、制御部３、通信インターフェース部４及び入出力インターフェース部５を備えている。

入出力インターフェース部５には、入力装置６及び出力装置７が接続されている。出力装置７としては、モニタ装置（家庭用テレビを含む）等の表示部を用いることができる。

入力装置６としては、キーボード装置及びマウス装置、及びマイクロホン装置の他、マウス装置と協働してポインティングデバイス機能を実現するモニタ装置を用いることができる。

記憶部２としては、例えばＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）等の記憶装置を用いることができる。記憶部２には、管理者設定マスタ１１、申請種別カテゴリ割付マスタ１２、組織マスタ１３、部署マスタ１４、ユーザマスタ１５、実テーブル１６、起票テーブル１７、及び、申請種別グループマスタ１８が記憶されている。また、記憶部２には、申請種別マスタ１９、コードマスタ２０、社員情報カテゴリマスタ２１、及び、更新制御プログラムが記憶されている。

管理者設定マスタ１１には、申請されたデータのデータベースに対する更新の承認権限のあるユーザ又は部署が記憶されている。申請種別カテゴリ割付マスタ１２には、更新の申請種別、及び、更新に承認者の承認が必要となるデータ種別（カテゴリ）が記憶されている。組織マスタ１３には、組織コード及び組織名等が記憶されている。部署マスタ１４には、部署コード、その部署が属する組織の組織コード、部署名等が記憶されている。ユーザマスタ１５には、ユーザ識別番号（ユーザＩＤ）、パスワード及びユーザ名等が記憶されている。

申請種別グループマスタ１８には、申請種別グループＩＤ及び申請種別グループ名等が記憶されている。申請種別マスタ１９には、申請種別コード、申請種別名、及び、申請種別グループコードが記憶されている。コードマスタ２０には、種別、コード値、及び、テーブル名が記憶されている。社員情報カテゴリマスタ２１には、カテゴリグループＩＤ、カテゴリＩＤ、カテゴリ名、表示フラグ、及び、表示順等が記憶されている。

実テーブル１６は、実データベースの一例であり、本登録されたデータの記憶領域である。実テーブル１６は、例えば「基本」のカテゴリのデータが記憶されるテーブル、「住所」のカテゴリのデータが記憶されるテーブル、「家族」のカテゴリのデータが記憶されるテーブル等のように、カテゴリ別の記憶領域（テーブル）を備えている。申請されたデータは、対応するカテゴリのテーブルに記憶される。

起票テーブル１７は、起票データベースの一例であり、実テーブル１６を更新する前のデータが、一時的に記憶される記憶領域となっている。更新制御装置１は、申請されたデータを、この起票テーブル１７に一旦記憶し、承認者の承認が得られた際に、起動テーブル１７から実テーブル１６にデータを移行し、実テーブル１６のデータ構成を変更（更新）する。これにより、承認者により承認が得られた正確なデータのみで、実テーブル１６を更新可能となっている。なお、起票テーブル１７も、実テーブル１６と同じ複数のカテゴリのテーブルで構成されている。

（更新制御装置の機能構成）
次に、更新制御装置１の制御部３は、記憶部２に記憶されている更新制御プログラムを実行することで、マスタ設定部３１、取得部３２、権限判別部３３、承認要否判別部３４、記憶制御部３５、表示制御部３６、及び、通信制御部３７として機能する。

マスタ設定部３１は、管理者設定マスタ１１及び申請種別カテゴリ割付マスタ１２等に対する各種データの設定を行う。取得部３２は、申請端末装置９を介して申請者から申請されたデータ等を取得する。権限判別部３３は、データの申請を行った申請者の、実テーブル１６に対する更新の権限の有無を判別する。承認要否判別部３４は、更新が申請されているカテゴリのテーブルは、更新に承認者の承認を必要とするテーブルであるか否かを判別する。

記憶制御部３５は、承認者により承認前のデータを、起票テーブル１７に一旦記憶しておき、承認後に、実テーブル１６に記憶する。表示制御部３６は、管理者設定マスタ１１及び申請種別カテゴリ割付マスタ１２等に対する各種データの設定画面を出力装置７に表示する。通信制御部３７は、申請端末装置９及び承認端末装置１０と通信を行う。通信制御部３７は、申請端末装置９から、更新するデータを受信する。また、通信制御部３７は、承認端末装置１０と通信を行い、申請されたデータによる実テーブル１６の更新の承認を得る。

（比較例の更新形態）
図２は、実施の形態の更新制御システムに対して比較例となる更新制御システムのデータベースの更新形態を示す図である。この図２において、東京人事部の社員Ａ、及び、関西支社の社員Ｇは、共にデータベースの更新の権限を有するユーザである。この図２に示すように、比較例となる更新制御システムの場合、データベースの更新の権限があれば、データベースに対して自由にアクセスしてデータベースの更新を行うことが可能であった。

このため、例えば関西支社等の拠点担当者（＝権限の無い社員Ｇ）により申請された社員情報等のデータが、精査が行われないまま、実データとしてデータベースに登録され、誤ったデータであっても、そのまま人事のデータとして使用される不都合を生じていた。

人事諸届という申請から、ある特定の情報（家族情報又は住所情報等）は、社員本人で精査することができるが、関西支社等の拠点からの社員情報は、直接入力、又は、ファイルを受け入れての入力のうち、どちらかの入力形態で入力されるため、承認者が精査することは困難であった。

また、仮に、データベースのデータが正しいデータに修正されたとしても、データを変更する権限を有するユーザであれば、後から再度書き換えることも可能であった。

（実施の形態のシステム概要）
このようなことから、データベースの更新を行う場合、実施の形態の更新制御システムでは、承認者により精査された正確なデータを、データベースに更新するようになっている。

図３は、実施の形態の更新制御システムにおけるシステム動作の概要を示す図である。この図３に示すように実施の形態の更新制御システムの更新制御装置１は、データベース（テーブル）の更新が申請された場合、管理者設定マスタ１１を参照して、申請を行ったユーザが、データベースに対する更新権限を有するユーザであるか否かを判別する。また、更新が申請されているデータを記憶するテーブルが、承認者の承認を必要とするテーブルであるか否かを判別する。

申請を行ったユーザが、データベースに対する更新権限を有するユーザである場合、申請されたデータを実テーブル１６に対して更新する。また、更新が申請されているデータを記憶するテーブルが、承認者の承認を必要とするテーブルではない場合、申請されたデータを実テーブル１６に対して更新する。

これに対して、申請を行ったユーザが、データベースに対する更新権限を有するユーザではない場合、申請されたデータを起票テーブル１７に一旦記憶する。また、更新が申請されているデータを記憶するテーブルが、承認者の承認を必要とするテーブルである場合、申請されたデータを起票テーブル１７に、一旦記憶する。

更新制御装置１は、申請されたデータを起票テーブル１７に一旦記憶した場合、承認端末装置１０に対して、申請されているデータによる実テーブル１６の更新の承認申請を行う（図３の社員情報申請に相当）。承認者は、承認申請されたデータによる実テーブル１６の更新の承認又は却下を決定し、承認端末装置１０を介して更新制御装置１に通知する。

更新制御装置１は、承認端末装置１０を介して承認されたデータのみを、起票テーブル１７から実テーブル１６に移行して、実データベース１６を更新する。更新制御装置１は、承認者により承認されなかったデータは、起票テーブル１７から破棄（消去）し、実テーブル１６の更新を拒否（却下）する。これにより、承認者により承認されたデータのみを用いて、実テーブル１６を更新できる。

（管理者設定マスタの構成）
次に、図４は、実テーブル１６の更新の際に参照される管理者設定マスタ１１に対する承認者の設定を説明するための図である。一例ではあるが、管理者設定マスタ１１に対する設定は、図４（ａ）に示す東京本社側で行う。管理者設定マスタ１１に登録されたユーザ又は部署のユーザが、「管理者の承認なしで実データの更新権限を有するユーザ又は部署のユーザとなる。図４（ａ）及び図４（ｂ）の例は、「管理者の承認なしで実データの更新権限を有する「部署」として、東京人事部が、管理者設定マスタ１１に設定された例である。この場合、東京人事部の社員Ａ及び社員Ｂが、管理者の承認なしで実データの更新権限を有する。また、図４（ａ）及び図４（ｂ）の例は、「管理者の承認なしで実データの更新権限を有する「ユーザ」として、東京総務部の社員Ｃが、管理者設定マスタ１１に設定された例である。この場合、東京総務部の社員Ｃが、管理者の承認なしで実データの更新権限を有する。

すなわち、業務オペレータ等により、管理者設定マスタ１１に対する承認者の設定が指定されると、表示制御部３６は、図４（ｂ）に示す管理者設定画面を出力装置７に表示する。業務オペレータは、この管理者設定画面を介して、承認者とする部署又はユーザを設定操作する。

図４（ｂ）の例は、行の上段のレコードが、承認権限のある「部署」が設定されていることを示している。すなわち、この上段のレコードは、２０２１年１２月１日に、東京人事部の部署に対して承認権限が設定されたことを示している。また、図４（ｂ）の例は、行の下段のレコードが、承認権限のある「ユーザ」が設定されていることを示している。すなわち、この下段のレコードは、ユーザＩＤが「ＵｓｅｒＩｄＣ」の「社員Ｃ」に対して、承認権限が設定されたことを示している。このように、管理者マスタ１１には、選択的に承認権限が付与された部署又はユーザを示す情報が記憶（設定）される。

図５は、管理者設定マスタ１１に登録される部署又はユーザの各種情報が、他のマスタから取得されて管理者設定マスタ１１に登録される様子を示す図である。この図５に示すように、上述の東京人事部の社員等から承認者とする部署が指定されると、マスタ設定部３１は、図５（ａ）に示す組織マスタ１３から組織コード及び組織改定日時を取得すると共に、図５（ｂ）に示すように部署マスタ１４から組織コード、組織改定日時、及び、部署コードを取得し、図５（ｃ）に示すように管理者設定マスタ１１に設定（登録）する。同様に、上述の東京人事部の社員等から承認者とするユーザが指定されると、マスタ設定部３１は、図５（ｄ）に示すようにユーザマスタ１５からユーザＩＤを取得し、図５（ｃ）に示すように管理者設定マスタ１１に設定（登録）する。

（申請種別カテゴリ割付マスタの設定）
次に、図６は、更新の際に参照される申請種別カテゴリ割付マスタ１２に対する、承認を必要とするテーブルの設定を説明するための図である。業務オペレータ等により、申請種別カテゴリ割付マスタ１２に対する承認を必要とするテーブルの設定が指定されると、表示制御部３６は、図６（ｂ）又は図６（ｃ）に示す申請種別・社員情報カテゴリ割付画面を出力装置７に表示する。業務オペレータは、この申請種別・社員情報カテゴリ割付画面を介して、承認を必要とする各テーブル（カテゴリ名）及び申請種別を関連付ける設定操作を行う。

図６（ｂ）の例は、申請種別コードが「ＣＤ１０１０」の「社員属性」の申請種別に対して、「基本」、「住所」、「家族」、「学歴」及び「帰省先」のカテゴリの各テーブルが、承認を必要とするテーブルとして設定された例である。また、図６（ｃ）の例は、申請種別コードが「ＣＤ１０１０」の「社員属性」の申請種別に対して、異なるカテゴリの各テーブルが、承認を必要とするテーブルとして設定された例である。すなわち、図６（ｃ）の例は、申請種別コードが「ＣＤ１０２０」の「社員属性」の申請種別に対して、「基本」、「家族」、「社会保険」及び「税表区分」のカテゴリの各テーブルが、承認を必要とするテーブルとして設定された例である。

図６（ａ）は、各申請種別の承認ルートの一例を示している。すなわち、図６（ａ）に点線で示す承認ルートＡは、申請種別コードが「ＣＤ１０１０」の社員属性の承認ルートを示している。例えば横浜支社の横浜総務部の社員Ｆ、及び、関西支社の社員Ｇによる社員属性のデータによる実テーブル１６の更新は、東京人事部の社員Ａの最終承認を得るようになっている。

また、図６（ａ）に実線で示す承認ルートＢは、申請種別コードが「ＣＤ１０２０」の社員保険関連の承認ルートを示している。例えば、横浜支社の横浜総務部の社員Ｅ、及び、関西支社の社員Ｇによる社員保険関連のデータによる実テーブル１６の更新は、東京総務部の社員Ｄの承認を得た後に、社員Ｃの最終承認を得るようになっている。

図７は、申請種別カテゴリ割付マスタ１２に、申請種別及びカテゴリ（テーブル）が関連付けされて登録される様子を示す図である。マスタ設定部３１は、図７（ａ）に示す申請種別グループマスタ１８及び図７（ｂ）に示す申請種別マスタ１９を参照して例えば「ＣＤ１０１０」等の申請種別コードを取得し、図７（ｃ）に示すように申請種別カテゴリ割付マスタ１２に設定（登録）する。

また、マスタ設定部３１は、図７（ｄ）に示すコードマスタ２０を参照することでテーブル名を取得し、図７（ｅ）に示す社員情報カテゴリマスタ２１を参照することで、カテゴリグループＩＤ、カテゴリＩＤ及び表示順を取得して、図７（ｃ）に示すように、申請種別カテゴリ割付マスタ１２に設定（登録）する。これにより、申請種別及びカテゴリ（テーブル）を関連付けして申請種別カテゴリ割付マスタ１２に登録することができる。

（テーブルの更新動作）
次に、図８のフローチャートを用いて、更新制御装置１におけるテーブルの更新動作を説明する。制御部３は、記憶部２に記憶されている更新制御プログラムに基づいて、この図８のフローチャートに示す各処理を実行する。まず、ステップＳ１では、通信制御部３７が、申請端末装置９からネットワーク８を介して送信された、更新申請を行うデータを、通信インターフェース部４を介して受信し、取得部３２が、受信されたデータを取得する。

次に、取得されたデータには、申請を行っているユーザの部署情報、ユーザＩＤ、及び、申請種別を示す申請種別コードが付されている。このため、ステップＳ２では、権限判別部３３が、ステップＳ１で取得されたデータに付されているユーザの部署情報及びユーザＩＤに基づいて、図５（ｃ）に示す管理者設定マスタ１１を参照する。そして、取得されたデータに付されているユーザの部署情報又はユーザＩＤのうち、少なくとも一方が、管理者設定マスタ１１に登録されているか否かを判別する。

取得されたデータに付されているユーザの部署情報又はユーザＩＤのうち、少なくとも一方が、管理者設定マスタ１１に登録されているということは（ステップＳ２：Ｙｅｓ）、現在、申請を行っているユーザは、更新権限を有するユーザであることを示している。この場合、処理がステップＳ３に進み、記憶制御部３５が、申請されているデータのカテゴリに対応する実テーブル１６を、申請されたデータで更新する。

これに対して、取得されたデータに付されているユーザの部署情報又はユーザＩＤのうち、少なくとも一方が、管理者設定マスタ１１に登録されていないということは（ステップＳ２：Ｎｏ）、現在、申請を行っているユーザは、更新権限の無いユーザであることを示している。この場合、処理がステップＳ４に進み、記憶制御部３５が、申請されているデータのカテゴリに対応する起票テーブル１７に対して、申請されたデータを一旦記憶する（仮登録）。

通信制御部３７は、起票テーブル１７に対して、申請されたデータが記憶されると、承認端末装置１０と通信を行い、承認者に対して、現在、申請されているデータによる実テーブル１６の更新の承認要求を行う。ステップＳ５では、記憶制御部３５が、承認者により実テーブル１６の更新が承認されたか否かを判別する。

承認者により、更新が承認された場合（ステップＳ５；Ｙｅｓ）、記憶制御部３５は、ステップＳ３において、現在、起票テーブル１７に一時的に記憶されているデータを、申請されているデータのカテゴリに対応する実テーブル１６に移行して更新を行う。これにより、承認者により承認された後のデータを、実テーブル１６に更新できるため、正確なデータで実テーブル１６を更新することができる。

これに対して、承認者により更新が却下された場合（ステップＳ５；Ｎｏ）、ステップＳ６において、却下の処理が行われる。この却下の処理としては、例えば起票テーブル１７に一時的に記憶しているデータを記憶制御部３５が消去して、通信制御部３７が、申請を行ったユーザの申請端末装置９に対して、更新が承認されず、却下されたことを示すエラーメッセージを送信する。これにより、承認者により承認されなかったデータで実テーブル１６が更新される不都合を未然に防止でき、正確なデータで実テーブル１６を更新することができる。

一方、ステップＳ２では、承認要否判別部３４が、現在、申請されているデータを更新するテーブルは、権限の無いユーザでも、更新が可能なテーブルに対するデータであるか否かを判別する。

すなわち、実施の形態の更新制御装置１の場合、申請されたデータにより、そのデータのカテゴリと同じカテゴリの実テーブル１６が更新される。このため、承認要否判別部３４は、申請されたデータのカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されているか否かを判別する。

申請されたデータのカテゴリが、申請種別カテゴリ割付マスタ１２に登録されていないということは（ステップＳ２：Ｙｅｓ）、申請されたデータで更新しようとしている実テーブル１６は、更新に承認者の承認が不要であることを意味する。

このため、申請されたデータのカテゴリが、申請種別カテゴリ割付マスタ１２に登録されていない場合、記憶制御部３５は、ステップＳ３において、申請されたデータで、対応するカテゴリの実テーブル１６を更新する。

これに対して、申請されたデータのカテゴリが、申請種別カテゴリ割付マスタ１２に登録されているということは（ステップＳ２：Ｎｏ）、申請されたデータで更新しようとしている実テーブル１６は、更新に承認者の承認が必要であることを意味する。このため、記憶制御部３５は、ステップＳ４において、申請されているデータのカテゴリに対応する起票テーブル１７に、申請されたデータを一旦記憶する（仮登録）。

なお、テーブルとカテゴリは別の意味合いだが、実施の形態の更新制御装置１では、社員情報の登録の際に、属性をカテゴリとして分けて入力するようにしており、１カテゴリ＝１テーブルとなることから、テーブル＝カテゴリの意味合いで説明を行っている。

通信制御部３７は、起票テーブル１７に対して、申請されたデータが記憶されると、承認端末装置１０と通信を行い、承認者に対して、現在、申請されているデータによる実テーブル１６の更新の承認要求を行う。ステップＳ５では、記憶制御部３５が、この承認者により、更新が承認されたか否かを判別する。承認者により、更新が承認された場合（ステップＳ５；Ｙｅｓ）、記憶制御部３５は、ステップＳ３において、現在、起票テーブル１７に一時的に記憶されているデータを、申請されているデータのカテゴリに対応する実テーブル１６に移行して、実テーブル１６の更新を行う。これにより、承認者により承認された後のデータで実テーブル１６を更新できるため、実テーブル１６を正確なデータで更新することができる。

これに対して、承認者により更新が却下された場合（ステップＳ５；Ｎｏ）、ステップＳ６において、却下の処理が行われる。この却下の処理としては、例えば起票テーブル１７に一時的に記憶しているデータを記憶制御部３５が消去して、通信制御部３７が、申請を行ったユーザの申請端末装置９に対して、更新が承認されず、却下されたことを示すエラーメッセージを送信する。これにより、承認者により承認されなかったデータで実テーブル１６が更新される不都合を未然に防止でき、正確なデータのみで実テーブル１６を更新することができる。

（更新の具体例）
図９は、東京本社の東京人事部の社員Ａにより、住所の登録申請が行われた場合の例である。図９（ａ）に示す東京本社の東京人事部は、図４を用いて説明したように、承認を行う部署として管理者設定マスタ１１に設定されている。このため、東京本社の東京人事部の社員Ａは、承認者としての権限を有する。このため、社員Ａにより、図９（ｂ）に示すように社員情報管理画面を介して住所の登録が申請された場合、他の承認者の承認を得ることなく、住所のカテゴリの実テーブル１６に、申請された住所のデータが登録される。

これに対して、図１０は、関西支社の関西総務部の社員Ｇにより、住所の登録申請が行われた場合の例である。図１０（ａ）に示す関西支社の関西総務部の社員Ｇは、図４を用いて説明したように、管理者として管理者設定マスタ１１に設定されていない。このため、承認要否判別部３４は、図１０（ｂ）に示すように社員情報管理画面を介して申請されたデータの「住所」のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されているか否かを判別する。

申請されたデータの住所のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されている場合、住所のカテゴリのデータを更新する実テーブル１６は、更新に承認者の承認を必要とする。このため、記憶制御部３５が、社員Ｇから申請された住所のデータを、図１０（ｃ）に示すように、住所のカテゴリの起票テーブル１７に、一旦記憶する。この起票テーブル１７に記憶された住所のデータは、承認者の承認後に、住所のカテゴリの実テーブル１６に移行され、実テーブル１６が更新される。

図１１は、関西支社の関西総務部の社員Ｇにより、前職情報の登録申請が行われた場合の例である。図１１（ａ）に示す関西支社の関西総務部の社員Ｇは、図４を用いて説明したように、管理者として管理者設定マスタ１１に設定されていない。このため、承認要否判別部３４は、図１１（ｂ）に示すように社員情報管理画面を介して申請されたデータの「前職情報」のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されているか否かを判別する。

申請されたデータの前職情報のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されていない場合、前職情報のカテゴリのデータを更新する実テーブル１６は、更新に承認者の承認が不要となる。このため、図１１（ｃ）に示すように、記憶制御部３５が、社員Ｇから申請された前職情報のデータで、前職情報のカテゴリの実テーブル１６を更新する。

（管理者による申請又はカテゴリ未登録の場合の動作）
図１２は、更新を行う際に、承認者の承認が不要な管理者により、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタ１２に、申請されたデータのカテゴリが登録されていない場合における、更新制御装置１の動作をまとめて示す図である。この場合、新規登録が申請されたデータは、図１２（ａ）に示すように、起票テーブル１７に一時的に記憶されることなく、直接、実テーブル１６に登録される。また、「修正」も同様であり、図１２（ｂ）に示すように、実テーブル１６に記憶されているデータを、自由に修正することができる。また、「削除」も同様であり、図１２（ｃ）に示すように、実テーブル１６に記憶されているデータを、自由に削除することができる。

（管理者以外のユーザによる申請又はカテゴリが登録されている場合の動作）
図１３は、更新に承認者の承認が必要なユーザにより、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタ１２に、申請されたデータのカテゴリが登録されている場合における、更新制御装置１の動作をまとめて示す図である。この場合、新規登録が申請されたデータは、図１３（ａ）に示すように、起票テーブル１７に一時的に記憶される。そして、承認者の承認が得られた際に、起票テーブル１７から実テーブル１６に移行され登録される。

また、「修正」も同様であり、図１３（ｂ）に示すように、修正に用いられるデータは、起票テーブル１７に一時的に記憶される。そして、承認者の承認が得られた際に、起票テーブル１７から実テーブル１６に移行され、所望のデータの修正が行われる。また、「削除」も同様であり、図１３（ｃ）に示すように、削除に用いられるデータは、起票テーブル１７に一時的に記憶される。そして、承認者の承認が得られた際に、起票テーブル１７から実テーブル１６に移行され所望のデータの削除が行われる。

（実施の形態の効果）
以上の説明から明らかなように、実施の形態の更新制御装置１は、例えば関西支社等の拠点の人事担当者と東京本部の人事担当者（最終承認者）で同じ入力画面を使用するが、担当者及びテーブル単位で申請対象とするか否かを判断する。そして、最終承認者による承認が得られるまでの間、申請されたデータを起票データ１７に一時的に記憶しておき、最終承認者による承認が得られた際に、起票データ１７から実テーブル１６に、申請されたデータを移行して実テーブル１６の更新を行う。

これにより、承認者の承認が得られたデータを用いて実テーブル１６を更新でき、正確なデータでデータベース（実テーブル１６）を更新することができる。

また、関西支社等の拠点から申請されたデータを、ワークフローシステムの流れで処理することにより、承認者がデータを精査できるため、誤ったデータを排除できる。また、テーブル(カテゴリ）単位で申請可否を設定できるため、社員の属性情報単位毎に承認ルートを設定できる。これにより、例えば考課情報は上長の承認ルート、住所又は家族情報は人事部の承認ルート等のように、申請から承認までをスムーズに行うことができる。

［国連が主導する持続可能な開発目標（ＳＤＧｓ）への貢献］
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８及び目標９に貢献することが可能となる。

また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、ＳＤＧｓの目標１２、目標１３及び目標１５に貢献することが可能となる。

また、本実施形態により、統制、ガバナンス強化に寄与することができるので、ＳＤＧｓの目標１６に貢献することが可能となる。

［他の実施の形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、或いは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、更新制御装置１に関して、図示の各構成要素は機能概念的なものであり、必ずしも図示の如く物理的に構成されていることを要しない。

例えば、更新制御装置１が備える処理機能、特に制御部３及び制御部３にて行われる各処理機能については、その全部又は任意の一部を、ＣＰＵ（Central Processing Unit）および当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。なお、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて更新制御装置１に機械的に読み取られる。すなわち、ＲＯＭ又はＨＤＤ等の記憶部等には、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部３を構成する。

また、この更新制御装置１の更新制御プログラムは、更新制御装置１に対して任意のネットワークを介して接続された他のサーバ装置に記憶されていてもよく、必要に応じてその全部又は一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するための更新制御プログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Universal Serial Bus）メモリ、ＳＤ（Secure Digital）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（登録商標）（Electrically Erasable and Programmable Read Only Memory）、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory）、ＭＯ（Magneto-Optical Disk）、ＤＶＤ（Digital Versatile Disk）、及び、Blu-ray（登録商標） Disc等の任意の「可搬用の物理媒体」を含むものとする。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコード又はバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施の形態に示した更新制御装置１において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部２は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、及び、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、及び、ウェブページ用ファイル等を格納する。

また、更新制御装置１は、既知のパーソナルコンピュータ装置又はワークステーション等の情報処理装置で構成してもよく、また、任意の周辺装置が接続された情報処理装置で構成してもよい。また、情報処理装置は、本実施形態で説明した処理を実現させるソフトウェア（プログラム又はデータ等を含む）を実装することにより実現してもよい。

さらに、装置の分散・統合の具体的形態は図示するものに限られず、その全部又は一部を、各種の付加等に応じて又は機能付加に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

本発明は、データベースのデータ管理業務等に有用である。

１ 更新制御装置
２ 記憶部
３ 制御部
４ 通信インターフェース部
５ 入出力インターフェース部
６ 入力装置
７ 出力装置
８ ネットワーク
９ 申請端末装置
１０ 承認端末装置
１１ 管理者設定マスタ
１２ 申請種別カテゴリ割付マスタ
１３ 組織マスタ
１４ 部署マスタ
１５ ユーザマスタ
１６ 実テーブル
１７ 起票テーブル
１８ 申請種別グループマスタ
１９ 申請種別マスタ
２０ コードマスタ
２１ 社員情報カテゴリマスタ
３１ マスタ設定部
３２ 取得部
３３ 権限判別部
３４ 承認要否判別部
３５ 記憶制御部
３６ 表示制御部
３７ 通信制御部

Claims (6)

1. 更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された前記実データベースに設定されている承認要否情報に基づいて判別する承認要否判別部と、
   前記承認要否判別部の判別結果である、更新要求された前記データが記憶される前記実データベースが、更新時に承認者の承認が必要なデータベースであることを示す判別結果が得られた場合に、更新要求により前記実データベースに記憶するデータを、前記実データベースとは異なるデータベースである起票データベースに記憶し、承認者の承認が得られなかった場合は、起票データベースに記憶されたデータによる前記実データベースの更新は却下し、承認者の承認が得られた場合に、前記起票データベースに記憶したデータを、前記実データベースに移行して記憶する記憶制御部と、
   を有する更新制御装置。
2. 前記実データベースの更新要求を行ったユーザにおける、前記実データベースに対する更新権限の有無を判別する権限判別部を、さらに備え、
   前記記憶制御部は、前記権限判別部の判別結果である、前記実データベースに対する更新要求を行ったユーザが、前記実データベースに対する更新権限を有するユーザであることを示す判別結果、又は、前記承認要否判別部の判別結果である、更新要求された前記データが記憶される前記実データベースが、更新時に承認者の承認が不要なデータベースであることを示す判別結果が得られた場合、更新要求された前記データを、前記起票データベースに記憶することなく、前記実データベースに記憶すること、
   を特徴とする請求項１に記載の更新制御装置。
3. 前記権限判別部は、管理者設定マスタに登録されている、前記実データベースに対する更新権限を有するユーザ、又は、前記管理者設定マスタに登録されている、前記実データベースに対する更新権限を有する部署のユーザを、前記実データベースに対する更新権限を有するユーザとして判別すること、
   を特徴とする請求項２に記載の更新制御装置。
4. 前記承認要否判別部は、更新を申請するデータの種別である申請種別と、前記実データベースに記憶されるデータの分類を示すカテゴリのうち、更新に承認者の承認が必要なカテゴリとが関連付けされた情報である前記承認要否情報が記憶された申請種別カテゴリマスタに、更新要求された前記データに対応するカテゴリを検出した場合に、更新要求された前記実データベースは、更新時に承認者の承認が必要なデータベースであると判別すること、
   を特徴とする請求項１から請求項３のうち、いずれか一項に記載の更新制御装置。
5. 承認要否判別部が、更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された前記実データベースに設定されている承認要否情報に基づいて判別する承認要否判別ステップと、
   記憶制御部が、前記承認要否判別ステップでの判別結果である、更新要求された前記データが記憶される前記実データベースが、更新時に承認者の承認が必要なデータベースであることを示す判別結果が得られた場合に、更新要求により前記実データベースに記憶するデータを、前記実データベースとは異なるデータベースである起票データベースに記憶し、承認者の承認が得られなかった場合は、起票データベースに記憶されたデータによる前記実データベースの更新は却下し、承認者の承認が得られた場合に、前記起票データベースに記憶したデータを、前記実データベースに移行して記憶する記憶制御ステップと、
   を有する更新制御方法。
6. コンピュータを、
   更新要求されているデータが記憶される実データベースは、更新時に承認者の承認が必要なデータベースであるか否かを、更新要求された前記実データベースに設定されている承認要否情報に基づいて判別する承認要否判別部と、
   前記承認要否判別部の判別結果である、更新要求された前記データが記憶される前記実データベースが、更新時に承認者の承認が必要なデータベースであることを示す判別結果が得られた場合に、更新要求により前記実データベースに記憶するデータを、前記実データベースとは異なるデータベースである起票データベースに記憶し、承認者の承認が得られなかった場合は、起票データベースに記憶されたデータによる前記実データベースの更新は却下し、承認者の承認が得られた場合に、前記起票データベースに記憶したデータを、前記実データベースに移行して記憶する記憶制御部として機能させること、
   を特徴とする更新制御プログラム。

Images