(57)【要約】【課題】  本発明では、複数の拠点に分散するデータベースについて、その修正内容を適切に反映させることを課題とする。【解決手段】  本発明では、上記の課題を解決するために、情報についての修正時刻を検知し、これと各データベースにおける「時刻」の関係に応じて、各データベースに当該修正を反映させるかを判断するものである。この際、各データベースの時刻については、隣り合うデータベース(時間的に)と修正時刻の関係、すなわち、修正時刻がこれら隣り合うデータベースの時刻の間にあれば、修正を反映させていく。また、本発明では、この判断を連続的に行い、各データベースへの反映を次々と実施していくことがより好適である。さらに、情報の反映は、修正により生じる差分に応じて実施することも本発明の一態様に含まれる。【選択図】  図１
2012173827.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して修正者利用端末を介して入力された情報について、複数のデータベースそれぞれに反映させるための複数データベースに対するプロビジョニング方法において、
前記修正者端末から修正指示を受付け、
前記修正指示における修正時間を検知し、
検知された前記修正時間と、前記複数のデータベースそれぞれの時刻の関係を検出し、
検出された関係に基づいて、前記複数のデータベースに対する修正の要否を判断することを特徴とする複数データベースに対するプロビジョニング方法。
【請求項２】
請求項１に記載の複数データベースに対するプロビジョニング方法において、
前記時刻の関係の検知は、時間的に隣り合うデータベースの時刻と、前記修正時間の関係を検出することを特徴とする複数データベースに対するプロビジョニング方法。
【請求項３】
請求項２に記載の複数データベースに対するプロビジョニング方法において、
前記時刻の関係の検知は、前記時間的に隣り合うデータベースの時刻の間に、前記修正時間が含まれるかを検知し、
前記修正の要否の判断は、前記修正時間が含まれると検知した場合に、前記修正が必要と判断することを特徴とする複数データベースに対するプロビジョニング方法。
【請求項４】
請求項３に記載の複数データベースに対するプロビジョニング方法において、
前記時刻の関係の検知および修正の要否の判断を、時間的に隣り合うデータベースそれぞれについて連続的に実行することで、複数のデータベースそれぞれに対して、前記修正指示に対応する修正を実行することを特徴とする複数データベースに対するプロビジョニング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の拠点に分散されたデータベースについて、修正などを反映（プロビジョニング）するための技術に関する。
【背景技術】
【０００２】
現在、企業などの組織体については、人事情報など組織体の活動において必要な情報をデータベースで管理している。これらの情報は、異動などに応じて反映させる必要がある。例えば、特許文献１では、この修正内容を即反映させ、これを即時公開できるように以下の構成を採っている。
【０００３】
利用者が必要な情報を、公開とほぼ同時に電子メール等で容易に入手でき、かつ更新も容易な人事異動情報管理システムを提供するために、サービスセンタ１１は、社会に公開された会社人事情報から人事異動情報を抽出し、抽出した人事異動情報をデータベース１４に格納し、抽出した人事異動情報中の氏名と利用者データベース１７−１〜１７−ｎに格納されている人事情報中の氏名との中で一致する氏名を抽出すると共に対応する前記利用者データベースの内容を抽出した人事異動情報により更新し、一致した氏名があった場合にその旨を利用者端末に通知する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３２８９４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
現在、企業等は、複数の拠点を有するものが多く、また、国外にも拠点を有することがある。このように複数の拠点を有する場合、それぞれが企業全体の情報を管理するデータベースを有することが多い。このような場合、１つのデータベースに修正内容を反映させるだけでは、有効な反映にならない。つまり、各データベースで内容に不一致が生じることになる。特に、拠点毎に時差のある場合、各拠点のシステム（データベース）の稼働時間に相違が生じこの点が顕著になる。
【課題を解決するための手段】
【０００６】
本発明では、上記の課題を解決するために、情報についての修正時刻を検知し、これと各データベースにおける「時刻」の関係に応じて、各データベースに当該修正を反映させるかを判断するものである。この際、各データベースの時刻については、隣り合うデータベース(時間的に)と修正時刻の関係、すなわち、修正時刻がこれら隣り合うデータベースの時刻の間にあれば、修正を反映させていく。また、本発明では、この判断を連続的に行い、各データベースへの反映を次々と実施していくことがより好適である。さらに、情報の反映は、修正により生じる差分に応じて実施することも本発明の一態様に含まれる。
【発明の効果】
【０００７】
本発明によれば、より効率的に組織体の情報を反映させることが可能になる。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態の概念を示す図。
【図２】本発明の一実施形態の処理の流れを示す図。
【図３】本発明の一実施形態におけるイベントの処理を説明するための図。
【図４】本発明の一実施形態で用いられるデータベースの内容を説明するための図。
【図５】本発明の一実施形態におけるデータ反映の内容を判断するための基準を説明する図。
【図６】本発明の一実施形態におけるプロビジョニングが発生した場合の処理を説明する図(その１)。
【図７】本発明の一実施形態におけるプロビジョニングが発生した場合の処理を説明する図(その２)。
【図８】本発明の一実施形態におけるIDリポジトリをチェックするプロセスIDPの処理内容を説明する図。
【図９】本発明の一実施形態において、ID情報が反映されたイベントリポジトリのデータ構造を示す図。
【図１０】本発明の一実施形態におけるイベントリポジトリに格納されたイベント内容を反映させる処理を説明する図。
【図１１】本発明の一実施形態におけるイベントの反映を説明するための図。
【発明を実施するための形態】
【０００９】
本発明の一実施形態について図面を用いて説明する。まず、本実施形態の処理の概要を図１を用いて説明する。図１のN3-1において人事部門が異動通知等の内容(入社手続き,退社手続き,プロフィール変更手続き等)を組織1のIDリポジトリIDRP_D1にID情報登録,削除,変更として入力する。ID情報登録,削除,変更などの情報は図１のN3-2において時刻毎のイベントリポジトリ(EVRP_T2,EVRP_T3,EVRP_T4)へ格納される。なお、図１に示すシステムとは、各都市（組織）毎に設けられたサーバの１つであって、今回の例では都市１（組織１）に設けられたサーバから都市２、３、４へプロビジョニングをする際に発生する処理である。なお、このサーバは、図示しないがいわゆるコンピュータで実現され、プログラムに従ってＣＰＵの如き演算装置でその処理を実行する。ここで、以下に記載した都市１や２などはそれぞれで設置ないし利用されるサーバを意味する。
【００１０】
この概要における処理の内容を、図2を流れ図を用いて説明する。図2のF1-1で、人事がIDRP_D1に何らかのID改変(ID情報登録,削除,変更)を行った事、すなわち、自身が有する情報を変更したことをトリガとして図2の処理が開始される。図1のEVRP_T2,T3,T4に改変されたID情報を改変された時間毎にイベントとして格納するために,F1-1-1で今回の改変されたID情報を取得する。本実施形態では、IDRP_D1の内容が図4のようなカラムで形成されていたとする。
【００１１】
F1-1で、都市１は、人事担当者から、入社などによるID追加であれば、追加するIDとその情報(姓,名,職位,勤務地等)の入力を受付ける。また、F1-1で、人事担当者から、退職などによるID削除であれば,削除するIDの入力を受付ける。さらに、F1-1で、人事担当者から、異動などによるID変更であれば変更するIDと変更属性(姓 等)と変更値(前田)等の入力を受付ける。なお、これらの処理での入力は、図示しないＰＣのような端末装置からネットワークを介して受付けられる。
【００１２】
次に、F1-1-1では、都市１がF1-1で人事担当者から入力された情報を、抽出メモリに保持する。またF1-1-2ではF1-1が発生した時刻をID改変時刻としてメモリに保持する。
【００１３】
次に、図3からイベントの処理方法を説明する。都市1（のサーバにおける記憶装置、以下同様）に存在するディレクトリIDRP_D1から時差の大きい都市2, 3, 4に存在するディレクトリIDRP_D2,D3,D4へ プロビジョニングを行うとする。 都市2, 3, 4へプロビジョニングを行う時刻はグリニッジ標準時刻でそれぞれT2,T3,T4とする。グリニッジ標準時刻0：00をT1とする。なお、ここでの「時差の大きい」とは、予め定めた時間以上ないし予めその都市毎に「時差の大きい」都市を特定したもののいずれでもよい。 
なお、本例では、一日一回バッチ処理でX月Y+1日T2で都市2に対して、プロビジョニングを行う際前回プロビジョニングを行ったX月Y日T2からX月Y+１日T2までのID改変を記録したイベント(改変)情報EV_(X月Y日,T2)が必要となる。X月Y日T2から次のプロビジョニング実行時間であるX月Y日T3までの差分情報をEV_(X月Y日,T2)とするとEV_(X月Y日,T2)は差分情報ev_(X月Y日,T2),ev_(X月Y日,T3),ev_(X月Y日,T4)を足し合わせることで求めることができる。すなわち、本実施形態では、イベント（改変）情報EV_（X月Y日,T2）の情報を算出し、これを都市２に対して要求する。なお、この算出に関しては、都市２で実行してもよい。つまり、都市１では、算出要求とそのパラメータを送信し、都市２で算出を実行する。
【００１４】
次に、F1-2の処理内容の前に、本処理で用いられる基準について図5を用いて、説明する。本基準は、F1-2で格納するリポジトリをID改変時刻から判断するための基準である。X月Y+1日T2のプロビジョニングが終わった後X月Y+1日T3以降のプロビジョニングに必要なのはイベント情報ev_(X月Y日,T3), ev_(X月Y日,T4), ev_(X月Y+1日,T2)のみなので,ev_(X月Y日,T2)を廃棄する。人事部門が書面などで入手した異動通知等の情報を元にIDRP_D1に対して行ったID改変(入社手続き,退社手続き,プロフィール変更手続き等)はID改変が発生した時刻毎のリポジトリに記録される。
【００１５】
次に、T2からT3の間にIDRP_D1に対してID改変(入社手続き,退社手続き,プロフィール変更手続き等)が発生したかどうかを、F1-1-2で取得したID改変時刻とT2T3の比較内容から判断し(F1-1-3) 、該当するイベントev_(*日、T2)をイベントリポジトリEVRP_T2に記録する(F1-2)。F1-1-4でT3からT4の間に発生したかどうかをID改変時刻とT3T4の比較内容から判断し(F1-1-4)、該当するイベントev_(*日、T3)はイベントリポジトリEVRP_T3に記録する(F1-3)。
【００１６】
このプロビジョニングは、時刻T2、T3、T4、になった際に毎日時限式に発生する。つまり、この発生をトリガとして、以下の処理を実行する。図7を用いてこの内容、つまり、プロビジョニングが発生した場合の処理を説明する。時刻T2、T3、T4となった場合にはF2-1、F2-2、F2-3へ遷移し、IDリポジトリをチェックするプロセスIDP(T2、3、4）を呼び出し、当該チェックを実行する。この処理の内容を図６を用いて説明する。
【００１７】
次に、図7を用いて、F2-1、F2-2、F2-3で実施されるプロビジョニングを行う組織のIDリポジトリとプロビジョニングを行う時刻の組み合わせを管理するデータ構造(status_D1)について説明する。F3-7のようにStatus_D1はプロビジョニングを行うIDリポジトリを一意に示す情報(IDRP_D*)が、都市１などのサーバに格納されている。F3-8のようにそれぞれのリポジトリ管理者によってあらかじめ決められた、IDRP_D*に連携する時刻T*が記録されている。またF3-9のように次のデータ格納先を示すアドレスも格納されている。
【００１８】
これらが一つのデータ構造となりF3-10のように一つのノードを形成している。F3-9aのようにノード毎にアドレスが定義されており、F3-9やF3-6はこの値を格納している。F3-6のように現在(この時点で)作業しているノードのアドレスを記録できるように、Point_Tという領域を用意する。
【００１９】
次に、図8を用いて、IDリポジトリをチェックするプロセスIDP(＊)の処理内容を説明をする。ここでは、ID改変時刻T*を与えられて、先日からID改変時刻のT*まで各イベントリポジトリをチェックすることになる。その詳細を以下、説明する。
【００２０】
まず、F3-0-1で、都市１は、status_D1よりT*が図7 F3-11に記録されているノードを探索し、このノードのアドレス(ADR_st_*)をPoint_Tに記録する。F3-0-2で、NextT()という命令でPoint_Tが示すノードの次のノードを取得し、Point_Tに上書きする。
【００２１】
F3-1で、都市１は、呼び出したCheckEV_RPによってPoint_Tのノードで管理するイベントを全件プロビジョニングを行う都市のIDRP_DT*へ反映した後、F3-2で次のノードを探索する。イベントの反映については図11を用いて後述する。各イベントリポジトリの探索が終わった場合、F3-4の判定がyesとなるので、F3-3でEvRP_T*のイベント情報を削除する。
【００２２】
次に、図9を用いて、F1-2、F1-3、F1-4でID情報が反映されたイベントリポジトリのデータ構造を説明する。図7のPoint_Tで指し示すノードに記録された時刻にプロビジョニングを行うイベントリポジトリをEV_RP_Point_Tとする。このイベントリポジトリEV_RP_Point_Tはイベントが発生した順に線形リストで管理されている（つまり、発生した順序が特定されるように記録しておけば構わない）。本実施形態では、F4-4で示すように線形リストの先頭ノードを記録するためにTopという領域を持つ。先頭ノードのアドレスを取得するにはTopEV(Point_T)という命令を用いる。またF4-5に示すように現在作業をしているノードについてはアドレスを保管する領域としてPoint_EVを用意する。NextEV(Point_EV)という命令を実行することで次のノードのアドレスを取得できる。
【００２３】
次に、図10を用いて、Point_Tの示すノードのイベントリポジトリに格納されたイベント内容を反映させる処理の内容を説明する。まず、F4-1で、都市１は、EV_RP_Point_Tのイベントリポジトリの先頭ノードをPoint_EVとして記録する。
Point_EVが終端ノードにたどり着くまでF4-2でIDRP_Point_Tイベント内容を反映し、F4-6でPoint_EVの次のノードを探索する。F4-3でNextEV(Point_EV)でNULLが検知されたとき終端ノードまで探索したと判定して処理を終了する。  最後に、図11を用いてイベントリポジトリEVRP_*からIDRP_*へイベントの反映する動作について説明する。例をあげるとIDRP_D1へID追加が発生したときEVRPにはCe01の情報が格納されている。同様にID削除が発生したときはCe02、ID変更が発生したときはCe03の情報が格納されているとする。格納されているイベントがCe01のようにID追加であった場合は、Ce04のようにIDRP_ ＊にIDデータの追加を行う。Ce02のようにID削除であった場合は、Ce05のようにIDRP_*から該当IDデータを削除する。CE03のようにID変更であった場合は、CE06のようにIDRP_*の該当IDデータを変更する。変更や削除のようにIDRP_*から該当するIDを発見できるようにCe08の項目IDはユニークであるとする。
【符号の説明】
【００２４】
Ｎ３−１…異動通知内容、Ｎ３−２…時刻毎イベントリポジトリ
【図１】
2012173827.tif 000003
【図２】
2012173827.tif 000004
【図３】
2012173827.tif 000005
【図４】
2012173827.tif 000006
【図５】
2012173827.tif 000007
【図６】
2012173827.tif 000008
【図７】
2012173827.tif 000009
【図８】
2012173827.tif 000010
【図９】
2012173827.tif 000011
【図１０】
2012173827.tif 000012
【図１１】
2012173827.tif 000013