ネットワークを介して修正者利用端末を介して入力された情報について、複数のデータベースそれぞれに反映させるための複数データベースに対するプロビジョニング方法において、前記修正者端末から修正指示を受付け、前記修正指示における修正時間を検知し、検知された前記修正時間と、前記複数のデータベースそれぞれの時刻の関係を検出し、検出された関係に基づいて、前記複数のデータベースに対する修正の要否を判断することを特徴とする複数データベースに対するプロビジョニング方法。請求項1に記載の複数データベースに対するプロビジョニング方法において、前記時刻の関係の検知は、時間的に隣り合うデータベースの時刻と、前記修正時間の関係を検出することを特徴とする複数データベースに対するプロビジョニング方法。請求項2に記載の複数データベースに対するプロビジョニング方法において、前記時刻の関係の検知は、前記時間的に隣り合うデータベースの時刻の間に、前記修正時間が含まれるかを検知し、前記修正の要否の判断は、前記修正時間が含まれると検知した場合に、前記修正が必要と判断することを特徴とする複数データベースに対するプロビジョニング方法。請求項3に記載の複数データベースに対するプロビジョニング方法において、前記時刻の関係の検知および修正の要否の判断を、時間的に隣り合うデータベースそれぞれについて連続的に実行することで、複数のデータベースそれぞれに対して、前記修正指示に対応する修正を実行することを特徴とする複数データベースに対するプロビジョニング方法。現在、企業等は、複数の拠点を有するものが多く、また、国外にも拠点を有することがある。このように複数の拠点を有する場合、それぞれが企業全体の情報を管理するデータベースを有することが多い。このような場合、1つのデータベースに修正内容を反映させるだけでは、有効な反映にならない。つまり、各データベースで内容に不一致が生じることになる。特に、拠点毎に時差のある場合、各拠点のシステムデータベースの稼働時間に相違が生じこの点が顕著になる。本発明では、上記の課題を解決するために、情報についての修正時刻を検知し、これと各データベースにおける時刻の関係に応じて、各データベースに当該修正を反映させるかを判断するものである。この際、各データベースの時刻については、隣り合うデータベースと修正時刻の関係、すなわち、修正時刻がこれら隣り合うデータベースの時刻の間にあれば、修正を反映させていく。また、本発明では、この判断を連続的に行い、各データベースへの反映を次々と実施していくことがより好適である。さらに、情報の反映は、修正により生じる差分に応じて実施することも本発明の一態様に含まれる。本発明によれば、より効率的に組織体の情報を反映させることが可能になる。本発明の一実施形態について図面を用いて説明する。まず、本実施形態の処理の概要を図1を用いて説明する。図1のN31において人事部門が異動通知等の内容を組織1のIDリポジトリIDRPD1にID情報登録削除変更として入力する。ID情報登録削除変更などの情報は図1のN32において時刻毎のイベントリポジトリへ格納される。なお、図1に示すシステムとは、各都市組織毎に設けられたサーバの1つであって、今回の例では都市1組織1に設けられたサーバから都市2、3、4へプロビジョニングをする際に発生する処理である。なお、このサーバは、図示しないがいわゆるコンピュータで実現され、プログラムに従ってCPUの如き演算装置でその処理を実行する。ここで、以下に記載した都市1や2などはそれぞれで設置ないし利用されるサーバを意味する。この概要における処理の内容を、図2を流れ図を用いて説明する。図2のF11で、人事がIDRPD1に何らかのID改変を行った事、すなわち、自身が有する情報を変更したことをトリガとして図2の処理が開始される。図1のEVRPT2T3T4に改変されたID情報を改変された時間毎にイベントとして格納するためにF111で今回の改変されたID情報を取得する。本実施形態では、IDRPD1の内容が図4のようなカラムで形成されていたとする。F11で、都市1は、人事担当者から、入社などによるID追加であれば、追加するIDとその情報の入力を受付ける。また、F11で、人事担当者から、退職などによるID削除であれば削除するIDの入力を受付ける。さらに、F11で、人事担当者から、異動などによるID変更であれば変更するIDと変更属性と変更値等の入力を受付ける。なお、これらの処理での入力は、図示しないPCのような端末装置からネットワークを介して受付けられる。次に、F111では、都市1がF11で人事担当者から入力された情報を、抽出メモリに保持する。またF112ではF11が発生した時刻をID改変時刻としてメモリに保持する。次に、図3からイベントの処理方法を説明する。都市1のサーバにおける記憶装置、以下同様に存在するディレクトリIDRPD1から時差の大きい都市234に存在するディレクトリIDRPD2D3D4へプロビジョニングを行うとする。都市234へプロビジョニングを行う時刻はグリニッジ標準時刻でそれぞれT2T3T4とする。グリニッジ標準時刻0:00をT1とする。なお、ここでの時差の大きいとは、予め定めた時間以上ないし予めその都市毎に時差の大きい都市を特定したもののいずれでもよい。なお、本例では、一日一回バッチ処理でX月Y1日T2で都市2に対して、プロビジョニングを行う際前回プロビジョニングを行ったX月Y日T2からX月Y1日T2までのID改変を記録したイベント情報EVが必要となる。X月Y日T2から次のプロビジョニング実行時間であるX月Y日T3までの差分情報をEVとするとEVは差分情報evevevを足し合わせることで求めることができる。すなわち、本実施形態では、イベント改変情報EVX月Y日T2の情報を算出し、これを都市2に対して要求する。なお、この算出に関しては、都市2で実行してもよい。つまり、都市1では、算出要求とそのパラメータを送信し、都市2で算出を実行する。次に、F12の処理内容の前に、本処理で用いられる基準について図5を用いて、説明する。本基準は、F12で格納するリポジトリをID改変時刻から判断するための基準である。X月Y1日T2のプロビジョニングが終わった後X月Y1日T3以降のプロビジョニングに必要なのはイベント情報evevevのみなのでevを廃棄する。人事部門が書面などで入手した異動通知等の情報を元にIDRPD1に対して行ったID改変はID改変が発生した時刻毎のリポジトリに記録される。次に、T2からT3の間にIDRPD1に対してID改変が発生したかどうかを、F112で取得したID改変時刻とT2T3の比較内容から判断し、該当するイベントevをイベントリポジトリEVRPT2に記録する。F114でT3からT4の間に発生したかどうかをID改変時刻とT3T4の比較内容から判断し、該当するイベントevはイベントリポジトリEVRPT3に記録する。このプロビジョニングは、時刻T2、T3、T4、になった際に毎日時限式に発生する。つまり、この発生をトリガとして、以下の処理を実行する。図7を用いてこの内容、つまり、プロビジョニングが発生した場合の処理を説明する。時刻T2、T3、T4となった場合にはF21、F22、F23へ遷移し、IDリポジトリをチェックするプロセスIDPについて説明する。F37のようにStatusD1はプロビジョニングを行うIDリポジトリを一意に示す情報が、都市1などのサーバに格納されている。F38のようにそれぞれのリポジトリ管理者によってあらかじめ決められた、IDRPDに連携する時刻Tが記録されている。またF39のように次のデータ格納先を示すアドレスも格納されている。これらが一つのデータ構造となりF310のように一つのノードを形成している。F39aのようにノード毎にアドレスが定義されており、F39やF36はこの値を格納している。F36のように現在作業しているノードのアドレスを記録できるように、PointTという領域を用意する。次に、図8を用いて、IDリポジトリをチェックするプロセスIDPの処理内容を説明をする。ここでは、ID改変時刻Tを与えられて、先日からID改変時刻のTまで各イベントリポジトリをチェックすることになる。その詳細を以下、説明する。まず、F301で、都市1は、statusD1よりTが図7F311に記録されているノードを探索し、このノードのアドレスをPointTに記録する。F302で、NextTという命令でPointTが示すノードの次のノードを取得し、PointTに上書きする。F31で、都市1は、呼び出したCheckEVRPによってPointTのノードで管理するイベントを全件プロビジョニングを行う都市のIDRPDTへ反映した後、F32で次のノードを探索する。イベントの反映については図11を用いて後述する。各イベントリポジトリの探索が終わった場合、F34の判定がyesとなるので、F33でEvRPTのイベント情報を削除する。次に、図9を用いて、F12、F13、F14でID情報が反映されたイベントリポジトリのデータ構造を説明する。図7のPointTで指し示すノードに記録された時刻にプロビジョニングを行うイベントリポジトリをEVRPPointTとする。このイベントリポジトリEVRPPointTはイベントが発生した順に線形リストで管理されているつまり、発生した順序が特定されるように記録しておけば構わない。本実施形態では、F44で示すように線形リストの先頭ノードを記録するためにTopという領域を持つ。先頭ノードのアドレスを取得するにはTopEVという命令を用いる。またF45に示すように現在作業をしているノードについてはアドレスを保管する領域としてPointEVを用意する。NextEVという命令を実行することで次のノードのアドレスを取得できる。次に、図10を用いて、PointTの示すノードのイベントリポジトリに格納されたイベント内容を反映させる処理の内容を説明する。まず、F41で、都市1は、EVRPPointTのイベントリポジトリの先頭ノードをPointEVとして記録する。PointEVが終端ノードにたどり着くまでF42でIDRPPointTイベント内容を反映し、F46でPointEVの次のノードを探索する。F43でNextEVでNULLが検知されたとき終端ノードまで探索したと判定して処理を終了する。最後に、図11を用いてイベントリポジトリEVRPからIDRPへイベントの反映する動作について説明する。例をあげるとIDRPD1へ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はユニークであるとする。