データを記憶するデータ記憶部と、前記データ記憶部に記憶されるデータを更新する複数のトランザクションの間で各トランザクションを確定させる確定手順情報を記憶する確定手順情報記憶部と、前記データを更新するトランザクションを受付けた場合に、当該トランザクションを実行して、前記データから確定前の更新データを生成するデータ生成部と、前記データ生成部によって実行されたトランザクションを確定させる場合に、前記データを更新元データとする確定済みデータを生成した確定済みトランザクションが存在するか否かを判定する判定部と、前記判定部によって確定済みトランザクションが存在すると判定された場合に、前記確定済みデータと前記確定手順情報とに従って前記確定前の更新データを再び更新して、前記トランザクションを確定させる確定部と、を有することを特徴とするデータベースサーバ装置。前記データ記憶部は、複数のデータ項目を有するレコードを前記データとして記憶し、前記確定手順情報記憶部は、前記データ項目ごとに前記確定手順情報を記憶し、前記データ生成部は、前記レコードを更新するトランザクションを受付けた場合に、当該トランザクションを実行して、前記データ項目を更新した確定前の更新レコードを生成し、前記判定部は、前記データ生成部によって実行されたトランザクションを確定させる場合に、前記レコードを更新元のレコードとする確定済みレコードを生成した確定済みトランザクションが存在するか否かを判定し、前記確定部は、前記判定部によって確定済みトランザクションが存在すると判定された場合に、前記確定済みレコードと前記確定手順情報とに従って、前記確定前の更新レコードの各データ項目を再び更新して、前記トランザクションを確定させることを特徴とする請求項1に記載のデータベースサーバ装置。前記データ記憶部が記憶するレコードは、当該レコードを更新元レコードとする前記確定済みレコードを特定する特定情報を有し、前記判定部は、前記データ生成部によって実行されたトランザクションを確定させる場合に、前記レコードが有する特定情報に基づいて、前記確定済みレコードを生成した確定済みトランザクションが存在するか否かを判定することを特徴とする請求項2に記載のデータベースサーバ装置。前記データ記憶部が記憶するレコードは、前記データ項目ごとに、当該データ項目が更新された否かを示す更新フラグを有し、前記確定部は、前記判定部によって確定済みトランザクションが存在すると判定された場合に、前記更新フラグに基づいて更新されたデータ項目を特定し、前記確定済みレコードと前記確定手順情報とに従って、特定したデータ項目を再び更新して、前記トランザクションを確定させることを特徴とする請求項2に記載のデータベースサーバ装置。前記確定部は、前記トランザクションを確定させる場合に、当該トランザクションを確定させる前記確定済みデータに対する他のトランザクションを排他し、当該トランザクションを確定した場合に、前記確定済みデータに対する他のトランザクションの排他を解除することを特徴とする請求項2に記載のデータベースサーバ装置。データベースサーバ装置がデータを更新するトランザクションを受付けた場合に、当該トランザクションを実行して、前記データから確定前の更新データを生成するデータ生成ステップと、前記データ生成ステップによって実行されたトランザクションを確定させる場合に、前記データを更新元データとする確定済みデータを生成した確定済みトランザクションが存在するか否かを判定する判定ステップと、前記判定ステップによって確定済みトランザクションが存在すると判定された場合に、前記確定済みデータと複数のトランザクションの間で各トランザクションを確定させる確定手順情報とに従って前記確定前の更新データを再び更新して、前記トランザクションを確定させる確定ステップと、を実行することを特徴とするデータベース更新方法。コンピュータに、データを更新するトランザクションを受付けた場合に、当該トランザクションを実行して、前記データから確定前の更新データを生成するデータ生成手順と、前記データ生成手順によって実行されたトランザクションを確定させる場合に、前記データを更新元データとする確定済みデータを生成した確定済みトランザクションが存在するか否かを判定する判定手順と、前記判定手順によって確定済みトランザクションが存在すると判定された場合に、前記確定済みデータと複数のトランザクションの間で各トランザクションを確定させる確定手順情報とに従って前記確定前の更新データを再び更新して、前記トランザクションを確定させる確定手順と、を実行させることを特徴とするデータベース更新プログラム。しかしながら、上述した従来の技術では、競合するトランザクションを同時に実行することができないという課題があった。例えば、排他制御を用いたデータベースサーバでは、競合するトランザクションを逐次化することでデータの整合性を保証するので、競合するトランザクションを同時に実行することができない。また、複数のトランザクションをまとめて処理する方法では、データベースサーバは、例えば、分岐する命令を判定するトランザクションを実行する場合、トランザクション内でデータを検索した結果によって条件を判定して次の処理を実行するので、トランザクション内で実行する処理の全てをデータベースに事前に送付することができない。アプリケーションの設計段階で、同時に実行中の他のトランザクションからの更新を考慮して、各トランザクションを実行するように設計することは困難であり、現実的ではない。本発明は、競合するトランザクションを同時に実行することができるデータベースサーバ装置、データベース更新方法及びデータベース更新プログラムを提供することを目的とする。データを更新する複数のトランザクションの間で、更新が競合した場合に、各トランザクションを確定させる確定手順情報を記憶する手段を設ける。データベースサーバは、データを更新するトランザクションを受付けた場合に、トランザクションを実行して、更新元データから確定前の更新データを生成する。そして、データベースサーバは、トランザクションを確定させる場合に、更新元データから確定済みデータを生成した他の確定済みトランザクションが存在するか否かを判定する。そして、データベースサーバは、他の確定済みトランザクションが存在する場合に、更新元データと確定済みデータと確定手順情報とに従って確定前の更新データを再び更新して、トランザクションを確定させる。競合するトランザクションを同時に実行することができる。以下に、本願の開示するデータベースサーバ装置、データベース更新方法及びデータベース更新プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。図1は、実施例1にかかるデータベースサーバ10の構成を示すブロック図である。図1に示すように、データベースサーバ10は、データ記憶部11と確定手順情報記憶部12とデータ生成部13と判定部14と確定部15とを有する。このデータベースサーバ10は、利用者端末200とネットワークを介して接続されており、データの検索、更新、削除などの各種処理を実行するトランザクションを受付ける。データ記憶部11は、データを記憶する。確定手順情報記憶部12は、データ記憶部11に記憶されるデータを更新する複数のトランザクションの間で各トランザクションを確定させる確定手順情報を記憶する。データ生成部13は、データを更新するトランザクションを受付けた場合に、当該トランザクションを実行して、データから確定前の更新データを生成する。判定部14は、データ生成部13によって実行されたトランザクションを確定させる場合に、データを更新元データとする確定済みデータを生成した確定済みトランザクションが存在するか否かを判定する。確定部15は、判定部14によって確定済みトランザクションが存在すると判定された場合に、確定済みデータと確定手順情報とに従って確定前の更新データを再び更新して、トランザクションを確定させる。データ生成部13は、トランザクション毎に新たなデータを更新し、同一のデータから別の新たなデータを生成したトランザクションが存在する場合に、確定部15は、確定手順情報に従って、トランザクションと他トランザクションを確定させる。したがって、実施例1にかかるデータベースサーバ10は、競合するトランザクションを同時に実行し、データの整合性を高めることができる。[実施例2にかかるデータベースサーバの構成]次に、実施例2にかかるデータベースサーバの構成を説明する。図2は、実施例2にかかるデータベースサーバ100の構成を示すブロック図である。図2に示すように、実施例2にかかるデータベースサーバ100は、通信制御I/F部110と確定手順情報DB121と確定手順情報DBバッファ122とデータベース123とデータベースバッファ124とログDB125と制御部130とを有する。このデータベースサーバ100は、利用者端末200とネットワークを介して接続されており、データの検索、更新、削除などのトランザクションを受付ける。なお、確定手順情報DB121と確定手順情報DBバッファ122とデータベース123とデータベースバッファ124とログDB125とは、例えば、半導体メモリ素子、又はハードディスクなどの記憶装置である。通信制御I/F部110は、少なくとも1つの通信ポートを有するインターフェースであり、他の装置と間でやり取りされる情報を制御する。例えば、通信制御I/F部110は、データベース123に記憶されるデータを参照するトランザクションを利用者端末200から受付け、データベース123の情報を出力する。また、通信制御I/F部110は、図示しない管理装置からの要求に応じて、確定手順情報DB121やログDB125等に記憶される各種情報を管理装置に出力する。確定手順情報DB121は、データベースのデータを更新する複数のトランザクションの間で各トランザクションを確定させる確定手順情報をデータベースのテーブルのデータ項目ごとに記憶する。図3は、確定手順情報DB121が記憶する情報の一例を示す図である。例えば、図3に示すように、確定手順情報DB121は、列名、列のデータ型、デフォルト値、列の制約情報、更新競合時の属性としてカラム1、Integer、0、NOTNULL、ConflictingOperationMaxを記憶する。同様に、確定手順情報DB121は、カラム2、Char、、、ConflictingOperationOverWrite、カラム3、Char、、、ConflictingOperationOverWrite、カラム4、Integer、、、ConflictingOperationMergeを記憶する。ここで、列名は、データ項目の列名を示し、例えば、カラム1、カラム2、カラム3、カラム4などが格納される。列のデータ型は、格納される値の形式を指定する情報を示す。例えば、列のデータ型には、整数を定義するIntegerや指定した文字数以下の文字列を定義するCharなどが格納される。デフォルト値は、後述する列の制約情報としてNOTNULLが定義されている場合に、列のデータ型に対応して設定される初期値の値を示す。例えば、列のデータ型がIntegerの場合には、デフォルト値は、0が格納される。列の制約情報は、データベースに無効なデータが入力されないように定義された制約についての情報を示す。例えば、列の制約情報には、NULL値の入力を禁止するNOTNULLが格納される。更新競合時の属性は、トランザクションが競合した場合に、各トランザクションを確定させる確定手順情報を示す。例えば、更新競合時の属性には、更新結果の差分を計算するMerge、コミット時刻が後の結果で上書きするOverWrite、より大きい値を設定するMax、より小さい値を設定するMinなどが格納される。また、更新競合時の属性には、他トランザクションによって更新されていれば、トランザクションをエラーに設定するError、利用者が定義した関数を呼び出して利用者論理でマージするFunctionなどが格納される。なお、更新競合時の属性についての詳細は後述する。図3の例では、確定手順情報DB121は、カラム1には、小数点を持たない精度の整数値が格納され、NotNULL制約によって初期値は0に設定されることを示す。また、カラム1のデータ更新が競合した場合には、より大きい値が設定されることを示す。同様に、カラム2には、1文字以下の文字列が格納され、データ更新が競合した場合には、コミット時刻が後の結果で上書きされることを示す。カラム3には、5文字以下の文字列が格納され、データ更新が競合した場合には、コミット時刻が後の結果で上書きされることを示す。カラム4には、小数点を持たない精度の整数値が格納され、データ更新が競合した場合には、差分を計算した値が設定されることを示す。確定手順情報DBバッファ122は、確定手順情報DB121が記憶する情報の一部もしくは全てを一時的に記憶する。図4は、確定手順情報DBバッファ122が記憶する情報の一例を示す図である。例えば、図4に示すように、確定手順情報DBバッファ122は、列数と列数毎に列名と列のデータ型とデフォルト値と列の制約情報と更新競合時の属性とを記憶する。ここで、列数は、カラムの数を示す。なお、列名と列のデータ型とデフォルト値と列の制約情報と更新競合時の属性とは、確定手順情報DB121が記憶する情報と同様であるので詳細な説明を省略する。データベース123は、各種情報を複数のデータ項目を有するレコードとして記憶する。図5は、データベース123がテーブルTBL1として記憶する情報の一例を示す図である。例えば、図5に示すように、データベース123は、レコードID、生成者ID、更新者ID、コミット時刻、世代ポインタ、更新フラグ1、カラム1、更新フラグ2、カラム2、更新フラグ3、カラム3、更新フラグ4、カラム4を対応付けて記憶する。ここで、レコードIDは、レコードを一意に識別する識別子であり、例えばR2が格納される。生成者IDは、レコードを生成した生成者やトランザクションを一意に識別する識別子であり、例えば、10が格納される。更新者IDには、レコードを追加、レコードを更新、レコードを削除するトランザクションのいずれかが実行された場合、レコードを追加、レコードを更新、レコードを削除するトランザクションを識別する識別子が格納される。したがって、更新者IDが入っているレコードは、そのIDが示すトランザクションで更新後のレコードに置き換えられたり、削除されたりして無効になったことを意味する。なお、レコードを削除するトランザクションが実行された場合、更新者IDには、生成者IDと同じトランザクションを識別する識別子の値が格納される。コミット時刻は、トランザクション終了時刻を示す時刻情報であり、例えば、1000が格納される。世代ポインタには、レコードを更新して新たなレコードを生成したレコードを識別するレコードIDが格納される。カラム1、カラム2、カラム3、カラム4は、確定手順情報DB121に記憶される確定手順情報の列のデータ型に従って設定されたデータ値を示し、例えば、100、A、Init、5000が格納される。更新フラグ1は、カラム1に格納される情報が更新されて生成されたものであることを示す。例えば、更新フラグ1には、カラム1に格納される値が更新された場合にyが格納される。また、更新フラグ1には、カラム1に格納される値が更新されていない場合にnが格納される。nが格納されていると言うことは、そのレコードが更新された時に当該のカラムは更新されず更新元の値を引き継いだことを意味する。なお、更新フラグ2、更新フラグ3及び更新フラグ4については更新フラグ1と同様であるので、詳細な説明は省略する。図5の例では、データベース123は、レコードIDR2で識別されるレコードは、生成者ID10で識別されるトランザクションによって1000に作成されたデータ値が100、A、Init、5000であり、データ値の全てが新たに作成されてコミットされたことを示す。同様に、データベース123は、レコードIDR4で識別されるレコードは、生成者ID10で識別されるトランザクションによって1000に作成されたデータ値が30、F、Init、3200であり、データ値の全てが新たに作成されてコミットされたことを示す。また、データベース123は、レコードIDR6で識別されるレコードは、生成者ID40で識別されるトランザクションによってカラム2とカラム4の値が更新されたデータ値が100、B、Init、4000であることを示す。また、データベース123は、レコードIDR7で識別されるレコードは、生成者ID50で識別されるトランザクションによってカラム1~カラム4の値が更新されたデータ値が20、C、Init、450であることを示す。また、データベース123は、レコードIDR8で識別されるレコードは、生成者ID50で識別されるトランザクションによってカラム3とカラム4の値が更新されたデータ値が100、A、Upd、4000であることを示す。また、データベース123は、レコードIDR9で識別されるレコードは、生成者IDと更新者IDとがともに50であるので、50で識別されるトランザクションによって作成され、何れかのレコードが削除されたことを示す。データベースバッファ124は、データベース123に記憶される情報の更新対象であるレコードのコピーやレコードのコピーから生成した更新レコードを一時的に記憶する。なお、データベースバッファ124が記憶する情報は、図5に一例を示した、データベース123が記憶する情報と同じであるので、説明を省略する。また、データベースバッファ124は、更新や削除する元になったレコードと、更新や削除追加により生成したレコードとのアドレスをレコードセットとして記憶する。図6は、データベースバッファが記憶するトランザクションのレコードセットの一例を示す図である。例えば、図6に示すように、データベースバッファ124は、トランザクションID、更新元レコードID、生成レコードID、処理を対応付けて記憶する。ここで、トランザクションIDは、トランザクションを識別する識別子であり、例えば40が格納される。更新元レコードIDは、更新する元や削除する元になったレコードを一意に識別する識別子であり、例えばR2が格納される。生成レコードIDは、更新、削除及び追加によって生成したレコードを一意に識別する識別子であり、例えばR6が格納される。処理は、トランザクションの種類がレコードを追加するトランザクションであるか、レコードを更新するトランザクションであるか、レコードを削除するトランザクションであるかを示し、例えば更新が格納される。図6に示す例では、データベースバッファ124は、トランザクションID40で識別されるトランザクションは、更新元レコードIDR2で識別される更新元レコードを更新して、生成レコードIDR6で識別される生成レコードが作成されたことを示す。また、トランザクションID50で識別されるトランザクションは、生成レコードIDR7で識別される生成レコードを追加したことを示す。トランザクションID50で識別されるトランザクションは、更新元レコードIDR2で識別される更新元レコードを更新して、生成レコードIDR8で識別される生成レコードが作成されたことを示す。同様に、トランザクションID50で識別されるトランザクションは、更新元レコードIDR4で識別される更新元レコードを削除して、生成レコードIDR9で識別される生成レコードが作成されたことを示す。ログDB125は、トランザクションの更新履歴情報を記憶する。この情報は、トランザクションのロールバック時に更新データを無効化する場合や、システムがダウンした場合にデータベースを最新状態にリカバリするために使用される。制御部130は、制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有する。制御部130は、定義受付け部131と定義情報管理部132と受付け部133とデータ操作部134とレコード操作部135とバッファ管理部136とトランザクション管理部137と更新確定部138とログ管理部139とを有する。例えば、制御部130は、ASICApplicationSpecificIntegratedCircuitやFPGAFieldProgrammableGateArrayなどの集積回路、又は、CPUCentralProcessingUnitやMPUMicroProcessingUnitなどの電子回路である。定義受付け部131は、データベース資源の定義を利用者から受付ける。また、定義受付け部131は、データベース資源の定義として、データ毎の更新競合時の属性をカラムごとに指定した確定手順情報を受付ける。例えば、定義受付け部131は、更新競合時の属性として、Merge、OverWrite、Max、Min、Error、Functionを利用者から受付ける。定義情報管理部132は、定義受付け部131によって利用者から受付けたデータベースの定義情報を確定手順情報DB121に格納させる。また、定義情報管理部132は、確定手順情報DB121から確定手順情報を読み出し、読み出した確定手順情報を確定手順情報DBバッファ122へ展開する。例えば、定義情報管理部132は、確定手順情報DB121が記憶する図3に示した情報を読み出し、図4に示すように確定手順情報DBバッファ122へ展開する。受付け部133は、利用者端末200からデータベース操作を受付ける。例えば、受付け部133は、データベースの参照、更新、トランザクションの開始及び終了を受付け、受付けた内容をデータ操作部134へ転送する。また、受付け部133は、利用者端末200からトランザクションのコミット処理を受付けた場合、データ操作部134へ通知する。データ操作部134は、受付け部133を介して利用者端末200から受付けたデータベース操作をデータ操作命令として解釈する。例えば、データ操作部134は、受付け部133からトランザクションの開始及び終了を受付けた場合、受付けた開始及び終了を解釈してトランザクション管理部137へ通知する。また、データ操作部134は、利用者端末200から受付けたトランザクションのアクセス手順を生成する。例えば、データ操作部134は、受付け部133が受付けたデータ操作命令と定義情報を参照し、データベース123へのアクセス手順を生成する。図7A~図7Cを用いて、データ操作部134によるデータベースへのアクセス決定を説明する。例えば、図7Aに示すSQL文は、利用者端末から入力されたもので、データ操作部134がデータベース123に記憶されるテーブルTBL1のレコードとして100、A、Init、5000、を追加するようにデータベースをアクセスする手順を作成する。また、図7Bに示すSQL文は、データ操作部134がデータベース123に記憶されるレコード100、A、Init、5000、のカラム2の値をB、カラム4の値をカラム4の値1000に更新するようにデータベースにアクセスする手順を作成する。また、図7Cに示すSQL文は、データ操作部134がデータベース123に記憶されるレコード100、A、Init、5000、のカラム3の値をUpd、カラム4の値をカラム4の値1000に更新するようデータベースをアクセスする手順を作成する。また、データ操作部134は、生成したアクセス手順をレコード操作部135へ転送し、データの検索や更新を実行させる。ここで、データ操作部134は、トランザクションが実行される独立性水準を記憶し、データ検索時にはトランザクションの開始時刻又はデータ操作命令の実行時刻のどちらのコミット済みデータを検索するのかをレコード操作部135へ通知する。レコード操作部135は、データベースの検索や更新、トランザクションの終了、ログの記録を実行する。なお、レコード操作部135は、実施例1にかかるデータ生成部13の一例である。すなわち、レコード操作部135は、データを更新するトランザクションを受付けた場合に、トランザクションを実行して、データから確定前の更新データを生成する。レコード操作部135は、データ操作部134からデータベースの検索を受付けた場合、バッファ管理部136を呼び出して、データベース123のレコードをデータベースバッファ124に展開する。また、レコード操作部135は、データ操作部134によって指示された手順に従い、データベース123を検索してレコードを返却する。また、レコード操作部135は、データ操作部134からSQL文を受付けた場合、データの更新を実行する。ここで、レコード操作部135は、更新の度に新たなレコードを作成し、レコード参照時には資源を排他しないので、たとえ同一のレコードを更新する場合でも、参照処理を排他待ちさせずに処理する。また、レコード操作部135は、バッファ管理部136に通知し、データベースバッファ124を取得する。例えば、レコード操作部135は、データを追加する場合、追加するレコードをデータベースバッファ124上に追加する。また、レコード操作部135は、更新フラグにyを格納することでレコード中のデータを更新したカラムを識別させる。上述した図5及び図7Aを例にして説明する。レコード操作部135は、データ操作部134から図7Aに示したSQL文を受付けた場合、図5のレコードIDR2で識別されるレコードを生成する。また、例えば、レコード操作部135は、データを更新する場合、データベースバッファ124上に展開された更新元のレコードをコピーし、コピーしたレコードを更新する。ここで、レコード操作部135は、レコード内の更新フラグにyを格納することでレコード中のデータを更新したカラムを識別させる。上述した図5、図7B及び図7Cを例にして説明する。レコード操作部135は、データ操作部134から図7Bに示したSQL文のアクセス手順を受付けた場合、図5のレコードIDR6で識別されるレコードを生成する。同様に、レコード操作部135は、データ操作部134から図7Cに示したSQL文を受付けた場合、図5のレコードIDR8で識別されるレコードを生成する。また、レコード操作部135は、データを削除する場合、直接データを削除せずに、データベースバッファ124上に削除用のレコードを生成する。上述した図5を例にして説明する。レコード操作部135は、レコードIDR4で識別されるレコードを削除する場合、削除用のレコードとして図5に示したレコードIDR9で識別されるレコードを生成する。また、レコード操作部135は、トランザクションで更新したレコードセットとして、更新、削除する元になった更新元レコードと、更新や削除、追加によって生成した生成レコードとをデータベースバッファ124上に記憶させる。上述した図6を例にして説明する。レコード操作部135は、更新や削除する元になったレコードと、更新や削除追加により生成したレコードとのアドレスを図6に示したレコードセットとしてデータベースバッファ124上に記憶させる。また、レコード操作部135は、更新前のレコードイメージと更新後のレコードイメージをログ管理部139に通知して、ログDB125にログを記録する。図2に戻り、バッファ管理部136は、データベースバッファ124上にデータが展開されていない場合、データベース123に格納されたデータを読み出し、データベースバッファ124へ展開する。例えば、バッファ管理部136は、レコードIDR2で識別されるレコードを変更してレコードIDR6で識別されるレコードを生成する場合、データベース123からレコードIDR2を読み出し、読み出したレコードをデータベースバッファ124に展開する。トランザクション管理部137は、トランザクションを統合的に管理する。例えば、トランザクション管理部137は、トランザクションをコミットする場合には、更新確定部138を呼び出し、他に同時走行していたトランザクションの最新の更新結果と、コミット対象のトランザクションの更新結果を、定義しておいた更新競合時の属性に従ってマージさせる。また、トランザクション管理部137は、トランザクションがロールバックする場合には、トランザクションで更新した結果を更新前のデータに復元する。更新確定部138は、トランザクション管理部137から通知を受付けた場合、レコード操作部135が生成した追加レコードの確定や更新レコードの確定を実行して、トランザクションをコミットする。ここでは、更新確定部138が追加レコードの確定を実行する場合と更新レコードの確定を実行する場合についてそれぞれ詳細に説明する。また、更新確定部138は、実施例1にかかる判定部14及び確定部15の一例である。すなわち、更新確定部138は、レコード操作部135によって実行されたトランザクションをコミットさせる場合に、データを更新元データとする確定済みデータを生成したコミット済みのトランザクションが存在するか否かを判定する。また、更新確定部138は、コミット済みのトランザクションが存在すると判定した場合に、確定済みデータと確定手順情報とに従って確定前の更新データを再び更新して、トランザクションをコミットさせる。[追加レコードの確定を実行する場合]更新確定部138が追加レコードの確定を実行する場合について説明する。更新確定部138は、レコード操作部135によって生成されたレコードに更新元レコードが存在しなければ、生成されたレコードを追加レコードであると判定する。続いて、更新確定部138は、生成レコードが追加レコードであると判定した場合、生成レコードにコミット時刻を格納して生成レコードを確定させる。上述した図5及び図6を例にして説明する。更新確定部138は、図6に示すレコードセットのトランザクションID50で識別されるトランザクションにおいて、レコードIDR7で識別されるレコードには、更新元レコードIDが格納されておらず、更新元レコードが存在しないと判定する。すなわち、更新確定部138は、レコードIDR7で識別されるレコードが追加レコードであると判定する。続いて、更新確定部138は、図5に示したレコードIDR7で識別されるレコードのコミット時刻に1302を格納する。この結果、更新確定部138は、レコードIDR7で識別される追加レコードを確定させる。[更新レコードの確定を実行する場合]また、更新確定部138は、生成されたレコードに更新元レコードが存在すれば、生成されたレコードを更新レコードであると判定し、更新レコードの確定を実行する。更新確定部138は、更新レコードの確定を実行する場合、同一の更新元レコードを更新するトランザクションが存在するか否かを判定する。同一の更新元レコードを更新するトランザクションが存在しない場合更新確定部138が同一の更新元レコードを更新するトランザクションが存在しないと判定した場合について説明する。更新確定部138は、更新元レコードを読み出し、世代ポインタが格納されているか否かを判定することで同一の更新元レコードを更新するコミット済みのトランザクションが存在するか否かを判定する。ここで、更新確定部138は、世代ポインタが格納されていないと判定した場合、同一の更新元レコードを更新するトランザクションが存在しないと判定する。続いて、更新確定部138は、読み出した更新元レコードを参照世代のレコードとして選択する。また、更新確定部138は、選択した参照世代のレコードのコミット処理を排他する。そして、更新確定部138は、参照世代のレコードに生成したレコードIDと更新者IDとを格納する。また、更新確定部138は、生成したレコードにコミット時刻を格納し、更新を確定する。上述した図5を用いて説明する。ここで、トランザクションID40で識別されるトランザクションとトランザクションID50で識別されるトランザクションとが同時に処理を開始し、トランザクションID40がコミットした後にトランザクションID50がコミットするものとして説明する。図6のレコードセットにおいて、更新確定部138は、トランザクションID40で識別されるトランザクションがレコードIDR2で識別されるレコードを更新元にしてレコードIDR6で識別されるレコードを生成したと判定する。更新確定部138は、トランザクションID40を確定させる場合、図5に示したレコードIDR2の世代ポインタには値が格納されていないと判定する。したがって、更新確定部138は、レコードIDR6と同一の更新元レコードを更新するコミット済みのトランザクションが存在しないと判定する。続いて、更新確定部138は、図8に示すように、レコードIDR2の世代ポインタにR6、更新者IDに40を格納する。そして、更新確定部138は、レコードIDR6のコミット時刻に1300を格納し、更新を確定する。なお、図8は、更新確定部によるデータの確定を示す図である。同一の更新元レコードを更新するトランザクションが存在する場合更新確定部138が同一の更新元レコードを更新するトランザクションが存在すると判定した場合について説明する。更新確定部138は、読み出した更新元レコードに世代ポインタが格納されていると判定した場合、同一の更新元レコードを更新するトランザクションが存在すると判定する。かかる場合、更新確定部138は、参照世代を選択し、選択した参照世代と、確定手順情報DBバッファ122に記憶された確定手順情報とに従って生成したレコードに格納された値を確定させる。参照世代の選択まず、更新確定部138による参照世代の選択について説明する。更新確定部138は、読み出した更新元レコードの世代ポインタに格納されているレコードIDを抽出し、抽出したレコードIDに該当するレコードを読み出す。ここで、抽出されたレコードIDを次の世代のレコードと定義する。そして、更新確定部138は、次の世代のレコードの世代ポインタが格納されているか否かを判定する。更新確定部138は、世代ポインタが格納されていないと判定した場合、次の世代のレコードを参照世代のレコードとして選択する。一方、更新確定部138は、世代ポインタが格納されていると判定した場合、世代ポインタが格納されていないレコードを読み出すまで上述した次の世代のレコードを抽出する処理を繰り返す。更新確定部138は、参照世代を選択した場合、選択した参照世代のコミット処理を排他する。上述した図8を用いて説明する。例えば、トランザクションID40がコミットした後に、トランザクションID50がコミットする場合を説明する。更新確定部138は、トランザクションID50がレコードIDR2を更新元にしてレコードIDR8を生成したと判定する。そして、更新確定部138は、レコードIDR2の世代ポインタを読み出し、図8に示すように、R6が格納されていると判定する。この結果、更新確定部138は、同一の更新元レコードを更新するトランザクションが存在すると判定する。続いて、更新確定部138は、次の世代のレコードとしてレコードIDR6を読み出し、世代ポインタが格納されているか否かを判定する。ここで、更新確定部138は、レコードIDR6の世代ポインタには値が格納されていないので、レコードIDR6をレコードIDR8の参照世代のレコードとして選択する。更新レコードの確定更新確定部138は、選択した参照世代のレコードと確定手順情報DBバッファ122に記憶された確定手順情報とに従って生成したレコードに格納された値を確定させる。例えば、更新確定部138は、更新フラグに格納された値がyであるかnであるかを判定し、カラムの値が更新されているか否かを判定する。ここで、更新確定部138は、更新フラグに格納された値がnである場合、カラムに格納された値が更新されていないと判定し、参照世代のカラムに格納された値を設定する。一方、更新確定部138は、更新フラグに格納された値がyである場合、カラムの値が更新されていると判定し、確定手順情報DBバッファ122に記憶された確定手順を読み出し、競合時の属性を判定する。図8に示す例では、更新確定部138は、レコードIDR8の更新フラグ1及び更新フラグ2に格納された値がnであるので、カラム1の値に100、カラム2の値にBを設定する。一方、更新確定部138は、レコードIDR8の更新フラグ3及び更新フラグ4に格納された値がyであるので、図4に示す確定手順情報DBバッファ122に記憶される確定手順情報からカラム毎に設定された競合時の属性を判定する。そして、更新確定部138は、判定した競合時の属性に従って、カラム3及びカラム4の値を設定する。競合時の属性更新確定部138は、競合時の属性として、Merge、Max、Min、OverWrite、Error、Functionを判定し、カラムの値を設定する。ここで、更新確定部138が判定する競合時の属性について説明する。例えば、更新確定部138は、カラムに設定された競合時の属性がMergeであると判定し、更新した差分値を参照世代のレコードの値に計算した結果を設定する。例えば、更新確定部138は、図8に示すようなレコードIDR8の更新フラグ4の値がyであるので、カラムの値が更新されていると判定し、確定手順情報DBバッファ122に記憶された確定手順を読み出す。ここで、カラム4の競合時の属性はMergeに設定されているので、更新確定部138は、参照世代であるレコードIDR6のカラム4の値から差分値を計算した値、3000を格納する。更新確定部138は、カラムに設定された競合時の属性がMaxであると判定した場合、更新した値と参照世代のレコード中の値との大小比較を行い、最大値を設定する。また、更新確定部138は、カラムに設定された属性がMinであると判定した場合、更新した値と参照世代のレコード中の値との大小比較を行い、最小値を設定する。更新確定部138は、カラムに設定された競合時の属性がOverWriteであると判定した場合、参照世代のレコードと更新したレコードのコミット時刻を比較する。ここで、更新確定部138は、更新したレコードのコミット時刻の方が古ければ、参照世代のレコードに格納された値を設定する。一方、更新確定部138は、参照世代のレコードのコミット時刻の方が古ければ、更新したレコードに格納された値を設定する。なお、かかる場合、更新確定部138は、レコード毎に格納されたコミット時刻を判定する。例えば、更新確定部138は、図8に示すようなレコードIDR8の更新フラグ3の値がyであるので、カラムの値が更新されていると判定し、確定手順情報DBバッファ122に記憶された確定手順を読み出す。ここで、カラム3の競合時の属性はOverWriteに設定されているので、更新確定部138は、参照世代であるレコードIDR6と更新したレコードレコードIDR8のコミット時刻を比較する。この場合、更新したレコードレコードIDR8のコミット時刻の方が古いので、更新確定部138は、カラム3の値にUpd格納する。更新確定部138は、カラムに設定された競合時の属性がErrorであると判定した場合、参照世代のレコードで更新されているか否かを判定する。ここで、更新確定部138は、参照世代で更新されていると判定した場合、トランザクションをキャンセルする。更新確定部138は、カラムに設定された競合時の属性がFunctionであると判定した場合、更新元、参照世代、追加レコードを引数に利用者が登録したファンクションを呼び出して、更新結果をマージする。ここで、Functionは、複数の利用者によって文章データの添削をするように単純にマージすることができない場合に用いられる校正機能である。具体的には、更新確定部138は、添削した文章データを追記する場合に、既に他の利用者によってデータが追記されているならば、元のデータの後ろに添削した文章データを追記する。続いて、更新確定部138は、レコードの更新を確定させた場合、生成したレコードIDと更新者IDとを参照世代のレコードに格納する。また、更新確定部138は、コミット時刻を確定させたレコードに格納する。図8に示す例では、更新確定部138は、レコードIDR8の更新を確定させた場合、参照世代のレコードであるレコードIDR6の世代ポインタにR8、更新者IDに50を格納する。また、更新確定部138は、レコードIDR8のコミット時刻に1307を格納する。また、更新確定部138は、一連のトランザクションとして実行されるレコードの全てを処理したか否かを判定する。更新確定部138は、全てのレコードを処理したと判定した場合、排他を開放し、トランザクションをコミットする。更新確定部138は、トランザクションをコミットする時にデータベースに加えた変更、すなわち、コミット時刻の記録や世代ポインタの格納、トランザクションが競合した場合の各カラムの更新確定結果をログ管理部139へ転送する。図9を用いてトランザクションをコミットした後のデータベースの状態の一例を説明する。図9は、更新確定部138がトランザクションをコミットした後のデータベースの状態の一例を示す図である。図5に示した例と比較し、図9に示すトランザクションをコミットした後のデータベースのレコードID=R2には、更新者IDに40、世代ポインタにR6が新たに格納される。レコードID=R4には、更新者IDに50、世代ポインタにR9が新たに格納される。レコードID=R6には、更新者IDに50、コミット時刻に1300、世代ポインタにR8が新たに格納される。レコードID=R7には、コミット時刻に1302が新たに格納される。レコードID=R8には、コミット時刻に1307が新たに格納される。また、レコードID=R8のカラム2の値がB、カラム4の値が3000に更新される。レコードID=R9には、コミット時刻に1309が新たに格納される。ログ管理部139は、トランザクションの更新情報をログDB125に格納する。例えば、ログ管理部139は、レコード操作部135によって更新されたレコードイメージを受信し、受信したレコードイメージをログDB125に格納する。また、ログ管理部139は、更新確定部138からトランザクションをコミットした後のデータを受信し、受信したレコードイメージをログDB125に格納する。また、ログ管理部139は、トランザクション管理部137によってロールバックすると判定された場合には、トランザクションで更新した結果を更新前のデータに復元する。[データベースサーバ100による処理の処理手順]次に、図10及び図11を用いて、実施例2にかかるデータベースサーバ100における処理の処理手順を説明する。ここでは、図10を用いて、実施例2にかかるデータベースサーバ100の更新確定部138によるコミット処理の処理手順を説明し、図11を用いて、更新確定部138によるマージ処理の処理手順を説明する。更新確定部138によるコミット処理の処理手順図10は、更新確定部138による処理の処理手順を示すフローチャートである。図10を用いて更新確定部138によるコミット処理の処理手順を説明する。更新確定部138は、受付け部133がコミットを受付けた場合ステップS101、Yes、更新レコードセットを一つ読み出すステップS102。そして、更新確定部138は、読み出したレコードの更新元レコードIDが存在するか否かを判定するステップS103。更新確定部138は、更新元レコードIDが存在すると判定した場合にはステップS103、Yes、更新元レコードを読み出し、読み出したレコードのコミット処理を排他するステップS104。続いて、更新確定部138は、更新元レコードの世代ポインタが格納されているか否かを判定するステップS105。ここで、更新確定部138は、世代ポインタが格納されていないと判定した場合ステップS105、No、世代ポインタと更新者IDとを直前の確定済みレコードに格納しステップS109、ステップS110の処理を実行する。一方、更新確定部138は、世代ポインタが格納されていると判定した場合ステップS105、Yes、世代ポインタが示すレコードを読み出して、読み出したレコードのコミット処理を排他するステップS106。続いて、更新確定部138は、読み出したレコードに世代ポインタが格納されているか否かを判定するステップS107。ここで、更新確定部138は、世代ポインタが格納されていると判定した場合ステップS107、Yes、ステップS106の処理に戻り、以降の処理を実行する。一方、更新確定部138は、世代ポインタが格納されていないと判定した場合ステップS107、No、読み出したレコードを排他して更新のマージ処理を実行するステップS108。続いて、更新確定部138は、世代ポインタと更新者IDとを直前の確定済みレコードに格納しステップS109、ステップS110の処理を実行する。更新確定部138は、更新元レコードIDが存在しないと判定した場合にはステップS103、No、生成したレコードにコミット時刻を格納するステップS110。続いて、更新確定部138は、更新レコードセットに格納された全てのレコードの処理を実行したか否かを判定するステップS111。ここで、更新確定部138は、更新レコードセットに格納された全てのレコードの処理を実行していないと判定した場合ステップS111、No、ステップS102の処理に戻り、以降の処理を実行する。一方、更新確定部138は、更新レコードセットに格納された全てのレコードの処理を実行したと判定した場合ステップS111、Yes、排他を開放しステップS112、処理を終了する。更新確定部138によるマージ処理の処理手順次に、図11を用いて更新確定部138によるマージ処理の処理手順を説明する。なお、この処理は、図10のステップS108に対応する。更新確定部138は、カラムを一つ選択しステップS201、選択したカラムに格納された情報を更新したか否かを判定するステップS202。ここで、更新確定部138は、選択したカラムに格納された情報を更新していないと判定した場合ステップS202、No、参照世代のレコードに格納された値を選択したカラムに格納しステップS203する。続いて、更新確定部138は、全てのカラムについて処理を実行したか否かを判定するステップS219。更新確定部138は、選択したカラムに格納された情報を更新したと判定した場合ステップS202、Yes、確定手順情報DBバッファ122に記憶された確定手順情報から選択したカラムの更新競合時の属性を判定するステップS204。そして、更新確定部138は、属性がMergeであるか否かを判定するステップS205。ここで、更新確定部138は、属性がMergeであると判定した場合ステップS205、Yes、更新した差分値を参照世代のレコードが格納する値に計算した結果を設定するステップS206。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。一方、更新確定部138は、属性がMergeではないと判定した場合ステップS205、No、属性がMax又はMinであるか否かを判定するステップS207。ここで、更新確定部138は、属性がMax又はMinであると判定した場合ステップS207、Yes、更新した値と参照世代のレコード値とを比較し、最大値又は最小値を設定するステップS208。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。一方、更新確定部138は、属性がMax又はMinではないと判定した場合ステップS207、No、属性がOverWriteであるか否かを判定するステップS209。ここで、更新確定部138は、属性がOverWriteであると判定した場合ステップS209、Yes、参照世代のコミット時刻よりも読み出したレコードのコミット時刻が古いか否かを判定するステップS210。ここで、更新確定部138は、読み出したレコードのコミット時刻よりも参照世代のコミット時刻が古いと判定した場合ステップS210、No、読み出したレコードの値を設定するステップS211。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。一方、更新確定部138は、参照世代のコミット時刻よりも読み出したレコードのコミット時刻が古いと判定した場合ステップS210、Yes、参照世代のレコードの値を設定するステップS212。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。一方、更新確定部138は、属性がOverWriteではないと判定した場合ステップS209、No、属性がErrorであるか否かを判定するステップS213。ここで、更新確定部138は、属性がErrorであると判定した場合ステップS213、Yes、参照世代のレコードが更新されているか否かを判定するステップS214。ここで、更新確定部138は、参照世代のレコードが更新されていると判定した場合ステップS214、Yes、トランザクションをキャンセルするステップS215。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。一方、更新確定部138は、参照世代のレコードが更新されてないと判定した場合ステップS214、No、読み出したレコードで更新した値を設定するステップS216。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。一方、更新確定部138は、属性がErrorではないと判定した場合ステップS213、No、属性がFunctionであると判定するステップS217。そして、更新確定部138は、利用者によって登録されたファンクションを読み出し、更新結果をマージするステップS218。続いて、更新確定部138は、全てのカラムについてマージ処理を実行したか否かを判定するステップS219。更新確定部138は、全てのカラムについて処理を実行していないと判定した場合ステップS219、No、ステップS201に戻り、以降の処理を実行する。一方、更新確定部138は、全てのカラムについて処理を実行したと判定した場合ステップS219、Yes、処理を終了する。[実施例2の効果]上述してきたように、本実施例では、レコード操作部135がデータベース123から読み出したレコードからデータベースバッファ124上に新たなデータを生成する。また、更新確定部138は、レコード操作部135が生成したレコードを確定する場合、同一の更新元レコードから生成したレコードが存在するか否かを判定する。そして、更新確定部138は、更新元が同一のレコードが存在する場合に、確定手順DBバッファ122に格納された確定手順情報に基づいて、データを確定させることで、競合するトランザクションを同時に実行することができる。また、本実施例にかかるデータベースサーバは、データとして複数のデータ項目を有するレコードを記憶し、データ項目ごとにレコードを確定させる確定手順情報を記憶する。したがって、データベースサーバは、データを更新する場合、データ項目ごとにデータを確定させることができるので、レコードの更新処理を効率的に実行できる。また、本実施例にかかるデータベースサーバは、レコードを更新した場合、レコードの更新したデータ項目ごとに更新フラグを付与するので、データを確定させる項目を判定することができるので、レコードの更新処理を効率的に実行できる。また、本実施例にかかるデータベースサーバは、更新元データからのデータを更新した場合、更新元データに世代ポインタを格納する。したがって、データベースサーバは、世代ポインタを読み出すことで同一の更新元データを更新するトランザクションが存在するか否かを判定することができる。また、本実施例にかかるデータベースサーバは、トランザクションのコミット処理を排他するが、更新処理を排他しないので、同一のデータを更新するトランザクションが存在した場合でも、トランザクションの排他待ちをしなくてもよい。したがって、データベースサーバは、更新競合時のレスポンスやスループットを向上させることができる。また、本実施例にかかるデータベースサーバは、アプリケーションとの対話処理にも適用できるので、アプリケーション設計者がトランザクションの排他を考慮してアプリケーションを設計しなくてもよい。したがって、データベースサーバは、アプリケーション設計者の負担を軽減することができる。また、本実施例にかかるデータベースサーバは、データベースのレプリケーションによって、主系DBと従系DBを用いる場合においても、更新ログをお互いに送付して反映することで、両系での更新を実現することが出来る。また、本願の開示するデータベースサーバは、排他制御やデータキャッシュを最新化させる同期処理を削減することができる。このため、従来クラウド環境を構築する場合に問題となった、頻繁な通信による同期処理を省略することができるので、スケールアウトの限界を克服できる。したがって、本願の開示するデータベースサーバは、クラウド環境下に適した大規模にスケールできるデータベースを提供する技術の一部として活用することができる。ところで、本願の開示するデータベースサーバは、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例3では、本願の開示するデータベースサーバの他の実施例について説明する。システム構成等本実施例において説明した各処理のうち自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文章中や図面中で示した処理手順、制御手順、具体的名称については、特記する場合を除いて任意に変更することができる。データベースサーバは、利用者端末からデータの検索、更新を受付けるものとして説明したが、これに限定されるものではない。例えば、データベースサーバは、利用アプリケーションサーバであってもよい。また、データベースサーバと利用者端末とが1対1で接続されるものとして説明したが、これに限定されるものではない。例えば、データベースサーバは、複数の利用者端末と接続されてもよい。ログ管理部139がログの採取を実行し、ログDB125へ記憶させるものとして説明したがこれに限定されるものではない。例えば、ログを記録するかわりに、トランザクション終了時にデータベースバッファの内容をデータベースに同期して永続化することで、ログを記録せずにデータベースの永続性を保証するようにしても良い。データ操作部134は、データの検索時にトランザクションの開始時刻又はデータ操作命令の実行時刻のどちらのコミット済みデータを検索するのかをレコード操作部135へ通知するものとして説明したが、これに限定されない。例えば、データ操作部134は、検索する時刻についての情報をアクセス手順と共にSQL文に格納し、レコード操作部135に転送してもよい。また、データの検索時に、レコード操作部135は、コミット時刻として、トランザクションの終了時の時刻を設定するように説明したがこれに限定されるものではない。例えば、レコード操作部135は、トランザクションの開始時刻でデータを検索してもよい。また、レコード操作部135は、従来のMVCCMultiVersionConcurrencyControlのトランザクションにとって有効な世代か無効な世代かを判定する読み取り世代の判定条件を変更することで、同一レコードを更新するトランザクションを同時に走行させる。レコード操作部135は、従来の判定条件の一つレコードの更新者IDが未設定であるをレコードの更新者IDが未設定でかつ、更新元のレコードではないに変更する。図12は、レコード操作部135によって読み取り可能と判定されたレコードIDをトランザクション毎に示す図である。ここで、説明の便宜上、スナップショット取得時において、次のトランザクションに割り当てられるトランザクションIDは100と仮定する。図12に示すように、例えば、上述した図6のレコードセットがスナップショット中であった場合、レコード操作部135は、トランザクションID40で識別されるトランザクションについて、レコードIDR1、R4、R5、R6を読み取り可能と判定する。また、レコード操作部135は、トランザクションID50で識別されるトランザクションについて、レコードIDR1、R5、R7、R8、R9を読み取り可能と判定する。更新確定部138は、カラムを一つ選択し選択した順序でマージ処理を実行するものとして説明したが、これに限定されない。例えば、更新確定部138は、複数のカラムのマージ処理を並列して実行しても良い。さらに、更新確定部138は、カラムを任意の選択順序で選択することが可能である。また、図11に示したステップS205、ステップS207、ステップS209、ステップS213の処理は、どちらを先に実行してもよい。また、図示した記憶部が格納する情報は一例に過ぎず、必ずしも図示のごとく情報が格納される必要はない。例えば、データベース123は、トランザクションの開始時刻を記憶するようにしてもよい。また、図示した各構成部は、機能概念的なものであり、必ずしも物理的に図示のごとく構成されていることを要しない。例えば、データベースサーバ100は、データ操作部134とレコード操作部135とは統合されてもよい。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。プログラムところで、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。図13は、データベース更新プログラムを実行するコンピュータシステムを示す図である。図13に示すように、コンピュータシステム300は、バス310とネットワークインターフェース320とHDD330とRAM340とCPU350とROM360とを有する。ここで、ネットワークインターフェース320は、図2に示した通信制御I/F部110に対応する。また、ROM360には、上記実施例と同様の機能を発揮するプログラムが予め記憶されている。つまり、図13に示すように、ROM360は、データ生成プログラム361とデータ判定プログラム362とデータ確定プログラム363とが予め記憶されている。そして、CPU350は、データ生成プログラム361とデータ判定プログラム362とデータ確定プログラム363とを読み出してRAM340に展開する。そして、CPU350は、データ生成プログラム361をデータ生成プロセス351として実行する。またCPU350は、データ判定プログラム362をデータ判定プロセス352として実行する。またCPU350は、データ確定プログラム363をデータ確定プロセス353として実行する。なお、データ生成プロセス351は、図2に示したレコード操作部135に対応する。また、データ判定プロセス352及びデータ確定プロセス353は、更新確定部138に対応する。また、HDD330には、図2に示した確定手順情報DB121に対応する確定手順情報テーブル331が設けられる。ところで、上記したプログラム361~363は、必ずしもROM360に記憶させておく必要はない。例えば、コンピュータシステム300に挿入されるフレキシブルディスクFD、CD-ROM、MOディスク、DVDディスク、光磁気ディスク、ICカードなどの可搬用の物理媒体に記憶させておくようにしてもよい。また、コンピュータシステム300の内外に備えられるハードディスクドライブHDDなどの固定用の物理媒体に記憶させておいてもよい。さらに、公衆回線、インターネット、LANLocalAreaNetwork、WANWideAreaNetworkなどを介してコンピュータシステム300に接続される他のコンピュータシステムに記憶させておいてもよい。そして、コンピュータシステム300がこれらからプログラムを読み出して実行するようにしてもよい。すなわち、このプログラムは、上記した可搬用の物理媒体、固定用の物理媒体、通信媒体などの記録媒体に、コンピュータ読み取り可能に記憶されるものである。そして、コンピュータシステム300は、このような記録媒体からプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。なお、この他の実施例でいうプログラムは、コンピュータシステム300によって実行されることに限定されるものではない。例えば、他のコンピュータシステムまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。