JP4396988B2 - データベースシステム - Google Patents

Description

本発明は、データベースシステムに関し、とくに時制データベースを扱うデータベースシステムに関する。

コンピュータが扱うデータベースでは、同一のデータに対し、複数のプログラムから同時に更新処理が行われる場合がある。このような同時更新によってその対象となるデータの整合性が失われる事態を防ぐために、更新の際には対象データに対して排他制御がなされる。すなわち、対象データにロックがかけられ、一つの処理が完了するまで他の処理は開始されないように制御される。
このようなロックにより、複数のユーザが同時に同一データを更新しても逐次的に処理され、整合性が保たれる。また、いわゆるデッドロックが発生した場合には、一方または両方のプログラムを強制終了させ、データ全体の矛盾の発生を防止する。

ここで、データを更新する処理は様々な種類のものがあり、更新処理に要する時間も様々である。たとえば、単一のデータを、更新要求が発生した時点でリアルタイムに更新する、いわゆるオンライン処理が要する時間は比較的短く、たとえば１秒以内に終了する。一方、大量のデータに対して同一の更新処理を行う、いわゆるバッチ処理が要する時間は比較的長く、たとえば数日以上かかる場合がある。
このため、バッチ処理がロックを伴って実行されると、長時間に渡ってオンライン処理が実行できなくなり、業務に支障を来す可能性がある。これを回避するために、実際のシステム運用では、バッチ処理はオンライン入力時間帯を避けて、たとえば夜間バッチ処理や休日・連休中のバッチ処理として実行されることが多い。

このような、バッチ処理の実行時間帯に関する制約を解消するために、ロックを伴わずにバッチ処理とオンライン処理とを同時に実行する技術が知られており、たとえば特許文献１に開示される。これは、オンライン処理が実行される際に、未済のバッチ処理があるかどうかを確認し、あればオンライン処理の直前または直後にそのバッチ処理を実行するというものである。

また、コンピュータが扱うデータベースにおいて、更新処理に要する時間によって更新時刻が前後する場合があるため、厳密な時刻でデータを入れ替えるような更新処理、たとえばある年の４月１日００：００：００の瞬間にデータが更新されるものの実現は困難である。このような更新処理を実現するためには、一般的に、データと関連して、そのデータが有効となる時間に関する情報を記録するデータベース、すなわち時制データベース（トランザクション時間データベース）が使用される。このような時制データベースは、非特許文献１に説明される。

特許第３５０８１５４号公報 天笠俊之、有次正義、金森吉成、「時間的に変化するデータに対する索引技術」、情報処理、社団法人情報処理学会、２００１年１０月、第４２巻、第１０号、ｐ．９７２〜ｐ．９７９

しかしながら、従来の技術では、時制データベースにおいて、バッチ処理とオンライン処理を同時に実行することはできなかった。
特許文献１の技術は、時制データベースのように厳密な時刻でデータを更新するものには適用できない。特許文献１の技術では、バッチ処理の完了時刻がオンライン処理の発生時刻に依存するため、現在まだ有効となっていない将来のバッチ処理済データが、オンライン処理が発生した時点で有効となってしまい、データ内容に不整合が発生する可能性があるからである。

この発明は、このような問題点を解決するためになされたものであり、時制データベースにおいて、バッチ処理とオンライン処理とを同時に実行する機能を有する、データベースシステムを提供することを目的とする。

上述の問題点を解決するため、この発明に係るデータベースシステムは、データベースに関する処理を行うデータベースシステムであって、データベースは、複数のレコードを含み、データベースは、レコードが、時間の経過につれて無効から有効となるデータと、そのデータが有効である有効時区間を表す情報と、検索に用いられるキーとを有する、時制データベースであり、処理の少なくとも一部は第一種の処理であり、第一種の処理は、第一種の処理の対象となるレコードに関連して、第一種の処理のそれぞれに関連付けられた時刻において、有効なデータを変更するものであり、データベースシステムは、第一種の処理に関連して、第一種の処理の対象となるレコードのキーと同一のキーを有する追加レコードを作成して時制データベースに追加する、第一更新部と、キーを含む検索条件を受け取るとともに、この検索条件に適合するレコードを時制データベースから抽出する、検索部とを備え、第一更新部は、追加レコードの有効時区間の開始時刻を、第一種の処理に関連付けられた時刻に基づいて指定し、それによって、追加レコードの有効時区間を、第一種の処理の対象となるレコードの有効時区間と少なくとも一部が重複するものとし、検索部は、検索条件に適合するレコードが複数存在する場合、所定の基準に基づいて一つのレコードを選択するものである。

データの少なくとも一部は、さらに、時間の経過につれて有効から無効となるものであり、第一種の処理に関連するレコードの有効時区間の終了時刻が、第一種の処理に関連付けられた時刻に基づいて指定されてもよい。
第一種の処理はバッチ処理であり、第一更新部は、対象となるレコードに対する排他制御を行わないものであってもよい。
所定の基準は有効時区間に関連してもよい。
所定の基準は、有効時区間について最も新しい開始時刻を有するレコードを選択する、第一の選択を行うという基準を含んでもよい。
所定の基準は、有効時区間について、最も新しい時間帯に属する開始時刻を有するレコードを選択する、第一の選択を行うという基準を含み、時間帯は、順に実行される２つの第一種の処理について、それぞれに関連付けられた時刻によって区画されてもよい。

処理の少なくとも一部は、第一種の処理とは異なる第二種の処理であり、データベースシステムは、さらに、第二種の処理に関連するレコードの、有効時区間の開始時刻を指定する、第二更新部を備えてもよい。
第二更新部は、さらに、第二種の処理に関連するレコードの、有効時区間の終了時刻を指定してもよい。
レコードは、さらに、有効時区間の開始時刻および終了時刻が、それぞれ、第一更新部および第二更新部のいずれによって指定されたものであるかを示す、開始区分および終了区分を表す情報を含み、所定の基準は、開始区分および終了区分に関連してもよい。
第二種の処理は、その処理の対象となるレコードに基づいて追加レコードを作成する処理を含むものであり、第二種の処理が、第一種の処理に関連付けられた時刻より前に実行される場合は、その第二種の処理において作成される追加レコードに対し、その第一種の処理を実行してもよい。
第二種の処理はオンライン処理であり、第二更新部は、対象となるレコードに対する排他制御を行ってもよい。

所定の基準は、さらに、第一の選択によって複数のレコードが選択された場合は、開始区分が第二更新部を示すレコードを優先して選択する、第二の選択を行ってもよい。
検索条件は、検索が実行される検索実行時刻を含み、所定の基準は、さらに、第二の選択によって複数のレコードが選択された場合は、終了時刻と、検索実行時刻とを比較し、終了時刻が検索実行時刻より新しい場合には、終了区分が第二更新部を示すか、または終了区分が第一更新部および第二更新部のいずれも示さないレコードを優先して選択する、第三の選択を行い、終了時刻が検索実行時刻より古い場合には、終了区分が第二更新部を示すレコード、終了区分が第一更新部を示すレコード、および、終了区分が第一更新部および第二更新部のいずれも示さないレコードの順に優先して選択する、第四の選択を行うという基準を含んでもよい。
複数のレコードのうち少なくとも一部のレコードは削除レコードであって、複数のレコードのうち、削除レコードと同一のキーを有するレコードはすべて無効であってもよい。
データベースシステムは、さらに、所定の基準に基づく選択において選択される可能性のないレコードの少なくとも１つを、時制データベースから削除する、削除部を備えてもよい。

この発明によれば、データベースシステムは、バッチ処理の際には、ロックをかけずに、重複する有効時区間を有するレコードを追加し、また、検索の際には、それらの間の優先順位に基づいてレコードを抽出する。このため、データベースシステムは、時制データベースにおいて、バッチ処理とオンライン処理とを同時に実行することができる。

以下、この発明の実施の形態を添付図面に基づいて説明する。
実施の形態１．
図１は、本発明に係るデータベースシステムである、データベースサーバ１の構成を示す。データベースサーバ１は周知の構成を有するコンピュータであり、情報を格納する記憶手段２０と、演算を行う演算手段４０とを備える。記憶手段２０はメモリおよびＨＤＤ（ハードディスクドライブ）を含み、演算手段４０はＣＰＵ（中央処理装置）を含む。
データベースサーバ１は、さらに、入力装置であるキーボードおよびマウス、出力装置であるディスプレイおよびプリンタ、通信ネットワークに対する入力装置と出力装置とを兼ねるネットワークインタフェースを備える。

記憶手段２０は、時制データベースに関連するデータを含むデータテーブル２８を格納するデータ格納部２６と、データテーブル２８に対して実行されるバッチ処理に関するデータを格納するバッチ更新情報部２２と、データテーブル２８に対して実行されるオンライン処理に関するデータを格納するオンライン更新情報部２４とを含む。
ここで、オンライン処理とは、データの更新を行う際にロック（排他制御）を伴う処理であり、バッチ処理とは、データの更新を行う際にロックを伴わない処理である。すなわち、あるオンライン処理によってあるデータに対する更新処理が開始された後、その更新処理が完了する前は、他のオンライン処理およびバッチ処理はそのデータの更新を行うことができないように、排他制御が実施される。一方、あるバッチ処理によってあるデータに対する更新処理が開始された後、その更新処理が完了する前であっても、オンライン処理および他のバッチ処理はそのデータの更新を行うことができる。

演算手段４０は、記憶手段２０に格納されるプログラム（図示せず）を実行することによって、複数の機能を実現する。すなわち、バッチ処理の実行を制御するバッチ処理部５２としての機能、バッチ処理部５２からの指示に応じてデータの更新を行うバッチ更新部４２としての機能、オンライン処理の実行を制御するオンライン処理部５４としての機能、オンライン処理部５４からの指示に応じてデータの更新を行うオンライン更新部４４としての機能、データテーブル２８に対する検索を実行する検索部４６としての機能、オペレータ等外部に対する入出力を実行する入出力部４８としての機能である。
ここで、バッチ処理を第一種の処理、オンライン処理を第二種の処理とし、バッチ更新部を第一更新部、オンライン更新部を第二更新部とする。

図２は、図１のデータテーブル２８の構成の例を示す。データテーブル２８は複数のレコードＲ１およびＲ２を含み、各レコードＲ１およびＲ２は、それぞれ複数のフィールドを含む。この例では、データテーブル２８は「住民情報」という名称を有するものであり、各住民の住所データに関する情報を含む。
キーのフィールドには、検索の際に用いられる、そのレコードの対象となる単一の概念を表す値、この例では住民を表す個人番号が格納される。なお、キーとレコードとは必ずしも一対一に対応するものではなく、後述するように、同一のキーを有する複数のレコードが存在する場合がある。
このキーが、オンライン処理によるロックの単位となる。すなわち、あるオンライン処理がキー００１を有するレコードの更新中であるときは、キー００１を有するレコードがすべてロックされ、後述のように、他のオンライン処理およびバッチがそのようなレコードのいずれかの更新を試みた場合には、ロックのため更新を行うことができないという旨のエラー情報が返される。

有効時区間のフィールドには、そのレコードの属性情報が実際に正当なものである期間について、その期間の開始時刻および終了時刻が格納される。現在から将来に向けて有効であるレコード、すなわち新たな変更が発生しない限り有効であるレコードについては、終了時刻は指定されない（あるいは、いわゆるｎｕｌｌ値が指定されてもよい）。図２において「−」のみを表記することによってこれを示す。終了時刻が指定されていない場合には、終了時刻は∞、すなわちそのコンピュータが扱える最も未来の時刻であるものとして扱われる。
なお、後述するように、同一のキーを有する複数のレコードについて、有効時区間が互いに重複する場合がある。すなわち、同一のキーを有するレコードのうち、ある一時点で有効なものが複数存在する場合がある。
また、有効時区間の単位は、たとえばそのコンピュータが扱える時間の最小単位が用いられる。ただし、本明細書においては、説明の便宜上、この最小単位が１分であるものとする。

更新プログラム区分のフィールドには、そのレコードの開始時刻を指定したプログラムの種別を表す開始区分と、そのレコードの終了時刻を指定したプログラムの種別を表す終了区分とが格納される。プログラムの種別は、更新処理においてロックを伴うかどうかを表すものであり、この例ではロックを伴う場合には「オンライン」、伴わない場合には「バッチ」が指定される。
このように、レコードには、有効時区間の開始時刻および終了時刻が、それぞれ、バッチ更新部４２およびオンライン更新部４４のいずれによって指定されたものであるかを示す、開始区分および終了区分を表す情報を含む。

属性情報のフィールドには、そのレコードに関連してオペレータ等の業務に使用される情報が格納される。この例では、住所、学区、氏名、および、そのレコードが追加された際の理由を表す異動事由が格納される。このレコードは、時間の経過につれて有効あるいは無効となるものであり、有効時区間の開始時刻より前では無効、開始時刻以降、終了時刻以前では有効、終了時刻より後では無効である。なお、詳細は後述するが、バッチ更新部４２、オンライン更新部４４、バッチ処理部５２、及びオンライン処理部５４において作成する抽出済レコード、処理済レコード、追加レコード、満了レコード、及び再追加レコードも同様の構成である。

図３は、図１のバッチ更新情報部２２に格納されるデータの構成を示す。バッチ更新情報部２２には、バッチ処理部５２およびバッチ更新部４２によって実行される、複数のバッチ処理のそれぞれに関する情報が格納される。
バッチ番号、バッチ処理論理名、およびバッチ名称は、そのバッチ処理を識別するための値である。
更新テーブルは、図１のデータテーブル２８のうち、そのバッチ処理が更新を行う対象がどれであるかを表す。

抽出時刻は、バッチ処理用に抽出されるデータが有効である時刻を表す。バッチ処理の対象となるレコードを抽出する際には、ある一時点において有効であるレコード、すなわち有効時区間にその一時点を含むレコードが特定のアルゴリズムに従って抽出される（このアルゴリズムは、検索部４６の処理に関して後述する）。抽出時刻は、その一時点を表す。このため、抽出時刻より前のオンライン処理による更新は、抽出されたレコードに反映されているが、抽出時刻より後のオンライン処理による更新は、たとえそのオンライン処理が実際にバッチ処理による更新が開始される前のものであっても、抽出されたレコードには反映されていない。

更新反映時刻は、そのバッチ処理によって更新された後のデータが実際に有効となる時刻を表す。すなわち、更新前のデータに対応するレコードの有効時区間は、更新反映時刻の直前に終了し、更新後のデータに対応するレコードの有効時区間は、更新反映時刻において開始される。
以上より、あるバッチ処理の抽出時刻および更新反映時刻と、ある時刻Ｔ１との間に、抽出時刻≦Ｔ１＜更新反映時刻となる関係が成り立つとき、そのバッチ処理は時刻Ｔ１において仕掛かり中であると言える。なお、実際のバッチ処理は、抽出時刻より後に開始されるが、更新反映時刻より前に処理が完了して、新規に追加するためのレコードが作成されているものとする。

図４は、図１のオンライン更新情報部２４に格納されるデータの構成を示す。オンライン更新情報部２４には、オンライン処理部５４およびオンライン更新部４４によって実行されるオンライン処理に伴うロックの情報が格納される。
テーブル名は、図１のデータテーブル２８のうち、そのオンライン処理が更新を行う対象がどれであるかを表す。
ロックキー情報は、該当のデータテーブル２８において、そのオンライン処理が更新を行う対象となるキーの値、すなわち図２の例では個人番号を表す。

以上のように構成されるデータベースサーバ１における処理の流れを、図５〜図９のフローチャートを用いて説明する。図５はバッチ処理部５２、図６はバッチ更新部４２、図７はオンライン処理部、図８はオンライン更新部４４、図９は検索部４６の処理の流れをそれぞれ示すものである。なお、入出力部４８についてはその処理の流れを特に説明しないが、入力装置からオペレータの入力を受け取り、またオペレータに対する出力を出力装置に送る機能を有する。

図５を用いて、バッチ処理部５２の処理の流れを説明する。
まず、バッチ処理部５２は、実行するバッチ処理に対応するバッチ処理論理名、バッチ番号、および更新テーブルを、図３に示す構成を有する図１のバッチ更新情報部２２から読み込む（ステップＳ１１）。
次に、バッチ処理部５２は、更新テーブルと、バッチ処理論理名に対応して記憶手段２０にあらかじめ定義されている検索条件とを、検索部４６に渡すとともに検索を指示する（ステップＳ１２）。ここで、検索条件は、データテーブル２８から特定のレコードを抽出するための条件の表現であり、たとえばＳＱＬ（structured query language）を用いて表現されるものである。また、検索条件は、検索対象とするデータテーブル２８を表す条件と、どの時点において有効なレコードを検索対象とするかという検索対象時刻を表す条件とを含む。

次に、バッチ処理部５２は、検索条件に従って検索部４６が抽出したレコード（以下、「抽出済レコード」と称する）を、検索部４６から受け取る（ステップＳ１３）。上記のステップＳ１２およびＳ１３によって、当該バッチ処理の対象となるレコードがバッチ処理部５２に入力されることになる。なお、ここで、データテーブル２８において抽出の対象となったレコードを、以下、「抽出元レコード」と称する。
次に、バッチ処理部５２は、抽出済レコードに対し、バッチ処理論理名に対応して記憶手段２０にあらかじめ定義されているバッチ処理を実行する（ステップＳ１４）。たとえば、「住所」フィールドに含まれる特定の文字列を異なる文字列で置き換える処理等が実行される。ここで、バッチ処理部５２が更新し得るフィールドは、図２に示すもののうち、キーおよび属性情報のみである。有効時区間および更新プログラム区分は、バッチ処理部５２によっては変更されない。
最後に、バッチ処理部５２は、処理が実行されたレコード（以下、「処理済レコード」と称する）を、バッチ更新部に渡す（ステップＳ１５）。

図６を用いて、バッチ更新部４２の処理の流れを説明する。
まず、バッチ更新部４２は、バッチ処理部５２から処理済レコードを受け取る（ステップＳ２１）。
次に、バッチ更新部４２は、受け取った処理済レコードに基づき、データテーブル２８に追加されるべきレコード（以下、「追加レコード」と称する）を作成する（ステップＳ２２）。

この追加レコードは、次のような内容を有する。
図２に示される各フィールドのうち、キーおよび属性情報は、バッチ更新部４２によっては更新されない（上述の図５のステップＳ１４において、バッチ処理部５２によって更新されている場合はある）。
有効時区間のうち開始時刻は、図３に示されるバッチ更新情報部２２において当該バッチ番号に対応する更新反映時刻が指定される。また、終了時刻は指定されない。これは、このレコードが追加レコードすなわち新たに作成されたレコードであり、有効でなくなる時点がとくに指定されていないことを意味する。
更新プログラム区分のうち開始区分は、「バッチ」が指定される。これは、その追加レコードが、更新の際にロックを伴わない処理、すなわちバッチ処理によって作成されたものであることを意味する。また、終了区分は指定されない。これは、上述のように終了時刻が指定されていないため、終了時刻を指定するプログラムが存在しないことを意味する。

次に、バッチ更新部４２は、データテーブル２８内の抽出元レコードに基づき、抽出元レコードを置き換えるべきレコード（以下、「満了レコード」と称する）を作成する（ステップＳ２３）。
この満了レコードは、図２に示される構成を有する抽出元レコードの、各フィールドのうち終了時刻および終了区分を、次のように変更することによって作成される。
終了時刻は、図３に示されるバッチ更新情報部２２において当該バッチ番号に対応する更新反映時刻が指定される。また、終了区分は、「バッチ」が指定される。これは、その追加レコードが、更新の際にロックを伴わない処理、すなわちバッチ処理によって終了時刻を指定されたものであることを意味する。

最後に、バッチ更新部４２は、作成された追加レコードおよび満了レコードを、更新対象のデータテーブル２８に追加する（ステップＳ２４）。
なお、ここで、抽出元レコードと追加レコード、または、抽出元レコードと満了レコードは、互いに重複する有効時区間を有する場合があるが、一方を不適当なものとして削除する等の処理は、ここでは行われない。これは、当該バッチ処理がロックを伴わない処理であり、また、ステップＳ２４の実行時点では更新反映時刻に至っていないため、同一のレコードに対して同時に異なる内容の更新がかかり不整合が発生するという事態を避けるために、すべての可能性に対応するデータを残しておくことに相当する。

次に、図７を用いて、オンライン処理部５４の処理の流れを説明する。
まず、オンライン処理部５４は、入出力部４８から検索条件を受け取る（ステップＳ３１）。これは、たとえば、ディスプレイに表示される操作画面に対し、オペレータが検索条件の入力操作を行うことに対応する。
次に、オンライン処理部５４は、受け取った検索条件を検索部４６に渡し、検索を指示する（ステップＳ３２）。

次に、オンライン処理部５４は、検索部４６から抽出済レコードを受け取る（ステップＳ３３）。上記のステップＳ３２およびＳ３３によって、当該オンライン処理の対象となるレコードがオンライン処理部５４に入力されることになる。
次に、オンライン処理部５４は、入出力部４８から変更内容を受け取る（ステップＳ３４）。これは、たとえば、ディスプレイに表示される操作画面において、オペレータが抽出済レコードの内容に変更を加えることに対応する。
次に、オンライン処理部５４は、受け取った変更内容に応じて抽出済レコードに変更を加え、処理済レコードを作成する（ステップＳ３５）。ここで、オンライン処理部５４が更新し得るフィールドは、図２に示すもののうち、キーおよび属性情報のみである。有効時区間および更新プログラム区分は、オンライン処理部５４によっては変更されない。

次に、オンライン処理部５４は、処理済レコードをオンライン更新部４４に渡す（ステップＳ３６）。
次に、オンライン処理部５４は、オンライン更新部４４から処理結果の通知を受け取る（ステップＳ３７）。
最後に、オンライン処理部５４は、受け取った処理結果の通知を入出力部４８に渡す（ステップＳ３８）。これは、たとえば処理が正常終了した旨が画面に表示されることに対応する。

次に、図８を用いて、オンライン更新部４４の処理の流れを説明する。
まず、オンライン更新部４４は、オンライン処理部５４から処理済レコードを受け取る（ステップＳ４１）。
次に、オンライン更新部４４は、後続処理のために、検索実行時刻として、現在時刻を保存する（ステップＳ４２）。ここではある変数Ｔに現在時刻を代入することによって保存を行う。

次に、オンライン更新部４４は、データテーブル２８のレコードのうち、処理済レコードに対応する抽出元レコードが有するキーをロックする（ステップＳ４３）。このロックは、図４に示す構成を有するオンライン更新情報部２４に、処理対象のデータテーブル２８の名称と、そのデータテーブル２８においてロックされるキーとを組み合わせて格納することによって行われる。
ここで、該当するデータテーブル２８および該当するキーの組合せがオンライン更新情報部２４に格納されていない場合、すなわち該当レコードがロックされていない場合には、ロックは正常終了となる。逆に、該当する組合せがすでにオンライン更新情報部２４に格納されている場合、すなわち該当レコードがすでにロックされている場合には、ロックは異常終了となる。または、異なる実施形態として、異常終了せずに、すでにかかっているロックが解除されるまで待ち、その後ロックを行って正常終了とするものであってもよい。

次に、オンライン更新部４４は、ステップＳ４３におけるロックが正常終了したかどうかを判定する（ステップＳ４４）。正常終了でない場合、すなわち該当レコードが他のオンライン処理によってすでにロックされている場合には、オンライン更新部４４はオンライン処理部５４に異常終了の結果を通知し（ステップＳ４５）、処理を終了する。
ロックが正常終了した場合には、オンライン更新部４４は、抽出元レコードに基づき、データテーブル２８の抽出元レコードを置き換えるべき満了レコードを作成する（ステップＳ４６）。

この満了レコードは、図２に示される構成を有する抽出元レコードの、各フィールドのうち終了時刻および終了区分を、次のように変更することによって作成される。
終了時刻は、ステップＳ４２における変数Ｔ、すなわち保存された検索実行時刻が指定される。これは、処理済レコードが、変数Ｔの時刻まで有効であるが、このオンライン処理によって更新された結果、その時刻より後では有効ではなくなることを意味する。また、終了区分には「オンライン」が指定される。これは、その満了レコードが、更新の際にロックを伴う処理、すなわちオンライン処理によって満了することとなったものであることを意味する。

次に、オンライン更新部４４は、上述のように作成された満了レコードで、データテーブル２８内の抽出元レコードを置き換えることにより更新する（ステップＳ４７）。
ステップＳ４７の後、オンライン更新部４４は、以下のステップＳ４８〜Ｓ５５からなるレコード追加処理を行う。
レコード追加処理において、まず、オンライン更新部４４は、処理済レコードに基づき、追加レコードを作成する（ステップＳ４８）。

この追加レコードは、次のような内容を有する。
図２に示される各フィールドのうち、キーおよび属性情報は、オンライン更新部４４によっては更新されない（上述の図７のステップＳ３５において、オンライン処理部５４によって更新されている場合はある）。
有効時区間のうち開始時刻は、ステップＳ４２における変数Ｔ、すなわち保存された検索実行時刻が指定される。また、終了時刻は指定されない。これは、このレコードが追加レコードすなわち新たに作成されたレコードであり、有効でなくなる時点がとくに指定されていないことを意味する。
更新プログラム区分のうち開始区分は、「オンライン」が指定される。これは、その追加レコードが、更新の際にロックを伴う処理、すなわちオンライン処理によって作成されたものであることを意味する。また、終了区分は指定されない。これは、上述のように終了時刻が指定されていないため、終了時刻を指定するプログラムが存在しないことを意味する。

次に、オンライン更新部４４は、バッチ更新情報部２２を検索し、処理対象のデータテーブル２８について仕掛かり中のバッチ処理に対応するレコードを抽出する（ステップＳ４９）。これは、図３に示す構成を有するバッチ更新情報部２２のレコードのうち、更新テーブルの値が処理対象のテーブルの名称と一致し、かつ、抽出時刻≦変数Ｔ＜更新反映時刻となるレコードを抽出することによって行われる。

次に、オンライン更新部４４は、ステップＳ４９の結果として抽出されたレコードがあるかどうかを判定する（ステップＳ５０）。抽出されたレコードがない場合、すなわちオンライン処理の対象となるデータテーブル２８についての仕掛かりバッチ処理がない場合には、オンライン更新部４４は、追加レコードを更新対象のデータテーブル２８に追加し（ステップＳ５１）、後述のステップＳ５６へと処理を進める。

抽出されたレコードがある場合、すなわちオンライン処理の対象となるデータテーブル２８についての仕掛かりバッチ処理がある場合には、オンライン更新部４４は、追加レコードに対して該当仕掛かりバッチ処理を実施する（ステップＳ５２）。このバッチ処理は、図５におけるステップＳ１４と同様に、追加レコードに対し、バッチ処理論理名に対応してあらかじめ定義されているバッチ処理と同等の機能を持つサブルーチンを実行するものである。なお、この処理の内容はバッチ処理であるが、ステップＳ４３において該当レコードがロックされた後での処理であり、後述のように更新プログラム区分上はオンライン処理として扱われる。
また、このステップＳ５２は、オンライン更新部４４がバッチ処理部５２をサブルーチンとして呼び出した後、バッチ処理部５２によって実行されるものであってもよい。

次に、オンライン更新部４４は、追加レコードの終了時刻および終了区分を、次のように変更する（ステップＳ５３）。
終了時刻は、図３に示されるバッチ更新情報部２２において当該バッチ番号に対応する更新反映時刻が指定される。また、終了区分は、「オンライン」が指定される。これは、その追加レコードが、更新の際にロックを伴う処理、すなわちオンライン処理によって終了時刻を指定されたものであることを意味する。

次に、オンライン更新部４４は、バッチ処理が実施された処理済追加レコードに基づき、データテーブル２８にさらに追加されるべきレコード（以下、追加レコードとの区別のため「再追加レコード」と称する）を作成する（ステップＳ５４）。

この再追加レコードは、次のような内容を有する。
図２に示される各フィールドのうち、キーおよび属性情報は、バッチ処理の内容に応じて、オンライン更新部４４によって更新される。
有効時区間のうち開始時刻は、図３に示されるバッチ更新情報部２２において当該バッチ番号に対応する更新反映時刻が指定される。また、終了時刻は指定されない。これは、このレコードが追加レコードすなわち新たに作成されたレコードであり、有効でなくなる時点がとくに指定されていないことを意味する。
更新プログラム区分のうち開始区分は、「オンライン」が指定される。これは、その追加レコードが、更新の際にロックを伴う処理、すなわちオンライン処理によって作成されたものであることを意味する。また、終了区分は指定されない。これは、上述のように終了時刻が指定されていないため、終了時刻を指定するプログラムが存在しないことを意味する。
次に、オンライン更新部４４は、作成された追加レコードおよび再追加レコードを、更新対象のデータテーブル２８に追加する（ステップＳ５５）。

ステップＳ５１またはステップＳ５５の実行が終了することによって、ステップＳ４８〜ステップＳ５５からなるレコード追加処理が終了する。
この後、オンライン更新部４４は、ステップＳ４３において実施された抽出元レコードのキーのロックを解除する（ステップＳ５６）。この解除は、図４に示す構成を有するオンライン更新情報部２４から、処理対象のデータテーブル２８の名称と、そのデータテーブル２８においてロックされるキーとの組合せを削除することによって行われる。
最後に、オンライン更新部４４は、オンライン処理部５４に正常終了の結果を通知し（ステップＳ５７）、処理を終了する。

次に、図９を用いて、検索部４６の処理の流れを説明する。
まず、検索部４６は検索条件を受け取る（ステップＳ７１）。ここで、検索の指示および検索条件は、図５のステップＳ１２においてバッチ処理部５２から渡される場合もあり、また、図７のステップＳ３２においてオンライン処理部５４から渡される場合もある。また、図５のステップＳ１２に関連して上述したように、検索条件は、検索対象とするデータテーブル２８を表す条件と、検索対象時刻を表す条件とを含む。

次に、検索部４６は、受け取った検索条件によって検索対象となるデータテーブル２８のレコードのうち、検索対象時刻において有効なものを抽出する（ステップＳ７２）。ここで、有効なレコードとは、そのレコードの有効時区間の開始時刻および終了時刻と、検索対象時刻との間に、開始時刻≦検索対象時刻＜終了時刻という関係が成り立つものである。
次に、検索部４６は、有効なレコードのうち、その他の検索条件に適合するものを抽出する（ステップＳ７３）。これは、たとえばＳＱＬによって表現される、キーおよび属性情報に関する条件と、各レコードのキーおよび属性情報とを比較することによって行われる。

次に、検索部４６は、抽出されたレコードのうち、同一のキーを有するレコードが複数あるかどうかを判定する（ステップＳ７４）。
同一のキーを有するレコードがただ一つしかない場合、検索部４６は処理を後述のステップＳ７８に進める。なお、図９のフローチャートには検索条件に適合するレコードが存在しなかった場合の処理はとくに明示されないが、この場合でも「同一のキーを有するレコードが複数ある」という条件は満たさないものとして、図９のフローチャートに従って処理を行ってもよい。この場合、抽出済レコードは実際には空データであってもよい。

同一のキーを有するレコードが複数ある場合、検索部４６は、それらのレコードのうち、有効時区間の開始時刻が最新であるもの、すなわち時刻の値が最大であるものを選択する（ステップＳ７５）。これを第一の選択とする。ここで、開始時刻が最新であるレコードが複数存在する場合には、該当の最新レコードをすべて選択する。例は図１５を用いて後述するが、バッチ処理の対象となるレコードと、対応する満了レコードとが存在する場合が、このようなケースに該当する。
次に、検索部４６は、選択されたレコードのうち、同一のキーを有するレコードが複数あるかどうかを判定する（ステップＳ７６）。同一のキーを有するレコードがただ一つしかない場合、検索部４６は処理を後述のステップＳ７８に進める。

同一のキーを有するレコードが複数ある場合、検索部４６は、それらのレコードの更新プログラム区分の開始区分および終了区分に応じてレコード間の優先順位を決定し、最も優先順位の高いレコードをただ一つ選択する（ステップＳ７７）。
図１０は、このステップＳ７７における選択の際の、優先順位の決定方法を示す。決定方法は、現在仕掛かり中のバッチ処理があるかどうかによって異なる。仕掛かり中のバッチ処理がある場合、すなわち図３に示すバッチ更新情報部のレコードに、抽出時刻≦検索実行時刻＜更新反映時刻となるものが存在する場合は、優先順位は図１０の表（ａ）に従って決定される。そうでない場合は、優先順位は図１０の表（ｂ）表に従って決定される。
なお、ここで、複数のバッチ処理が同時に仕掛かり中となることはないものとする。

表（ａ）において、開始区分がオンラインであるレコードは、常に、開始区分がバッチであるレコードよりも優先される。これを第二の選択とする。また、開始区分が同一である場合、終了区分がオンラインまたは指定なしのレコードは、終了区分がバッチであるレコードよりも優先される。これを第三の選択とする。これは、バッチ処理が仕掛かり中であるため、バッチによって終了時刻を指定されたレコードの優先順位が低くなることを意味する。
なお、同一の開始区分を有するレコードのうち、終了区分がオンラインであるレコードと、終了区分が指定されていないレコードとで優先順位が等しくなっているが（優先順位１および３の行）、これらのレコードが同時に存在することはない。

また、表（ｂ）において、表（ａ）と同様に第二の選択として、開始区分がオンラインであるレコードは、常に、開始区分がバッチであるレコードよりも優先される。また、表（ａ）と異なり、開始区分が同一である場合、終了区分がオンラインであるレコードが最優先であり、次に終了区分がバッチであるレコードが優先され、指定なしのレコードは優先順位が最低となる。これを第四の選択とする。これは、ロックによって整合性が保証されるオンライン処理の結果が最優先となり、処理が完了しているバッチ処理の結果がその次に優先されることを意味する。

このように、第二の選択の結果は、表（ａ）（ｂ）いずれによっても同一である。第二の選択によってもなお複数のレコードが選択される場合は、更新反映時刻すなわちバッチ処理の終了時刻と、検索実行時刻とが比較され、これによって表（ａ）を基準とするか表（ｂ）を基準とするかが決定される。
終了時刻が検索実行時刻より新しい場合には、第三の選択によって、表（ａ）に従って、終了区分がオンラインであるか、または終了区分が指定されていないレコードが優先して選択される。
終了時刻が検索実行時刻より古い場合には、第四の選択によって、表（ｂ）に従って、終了区分がオンラインであるレコード、終了区分がバッチであるレコード、および、終了区分が指定されていないレコードの順に優先して選択される。

このようにして、ステップＳ７４、Ｓ７６、あるいはＳ７７における処理の結果、ただ一つのレコードが選択される。検索部４６は、この選択されたレコードを抽出済レコードとして、検索の指示元であるバッチ処理部５２またはオンライン処理部５４に渡す（ステップＳ７８）。

以上に説明されるデータベースサーバ１の構成および動作をまとめると、次のようになる。
データベースサーバ１が管理する時制データベースのデータテーブル２８には、同一のキーを有する複数のレコードのうち、互いに重複する有効時区間を有するものが含まれる。
そして、データベースサーバ１は、データテーブル２８のレコード毎に、データを更新するプログラムの種別を、開始区分および終了区分として関連付ける。レコードの検索を行う際に、同一のキーを有する有効なレコードが複数存在する場合には、仕掛かり中のバッチ処理が存在するかどうかと、有効時区間の開始時刻と、開始区分および終了区分とに基づいてレコード間の優先順位を決定し、最も優先順位の高いレコードを選択する。
また、データベースサーバ１は、バッチ処理を行う際には、ロックを実施して更新前のデータを更新後のデータで置き換えるという処理ではなく、ロックを実施せずに、更新前のデータを含む抽出元レコードはそのまま残しておき、更新後のデータを含む追加レコードをデータテーブル２８に単純に追加するという処理を行う。
また、データベースサーバ１は、オンライン処理を行う際、抽出元レコードをロックするとともに、仕掛かり中のバッチ処理があるかどうかを参照する。仕掛かり中のバッチ処理がない場合には、従来の時制データベースと同様の処理を行う。すなわち、更新前のデータを含む満了レコードと、更新後のデータを含む追加レコードとを作成し、これらをデータテーブル２８に追加してロックを解除する。
仕掛かり中のバッチ処理がある場合には、更新前のデータを含む満了レコードと、オンライン更新後バッチ更新前のデータを含む追加レコードと、バッチ更新後のデータを含む再追加レコードとを作成し、これらをデータテーブル２８に追加してロックを解除する。

次に、データベースサーバ１において、オンライン処理およびバッチ処理がレコードを更新する際の具体例を以下に説明する。
例となるデータテーブル２８は、図２に示されるものとする。これは住民票に対応するものであってもよい。このデータテーブル２８に対して、バッチ処理として住居表示による更新が加えられる場合を想定する。
図１２および図１４は、処理の各段階におけるデータテーブル２８の内容を示す。

ここで、住居表示とは、建物すべてに住居番号を付番する処理のことである。一般的に、住所は、町名と土地の地番（不動産地番）で表されるが、新しい市街地の形成や道路の新設等によって、建物の所在が容易に確認しにくくなる場合がある。これに対応して、住所をわかりやすく表すために、「住居表示に関する法律」に基づいて行われ、対象となる地区（住居表示区域）にある建物すべてに住居番号を付番し、この住居番号をもって住所を表すのが住居表示である。

この住居表示を実施するために大量の住民票の住所が変更になり、この処理はバッチ処理として行なわれるものとする。また、すべてのレコードを処理するには長時間が必要となるため、図３に示すように、抽出時刻を２００５年３月２７日の２３：００とし、更新反映時刻を２００５年４月１日０：００とする。バッチ処理の仕掛かり中においても、住民の異動（転入、転居、転出等）によってオンライン処理による更新は発生する。

図１１、図１３、および図１５は、説明の便宜のため、図２、図１２、および図１４にそれぞれ示すデータテーブル２８の各レコードの、開始時刻および終了時刻、開始区分および終了区分を模式的に示すものである。各レコードの有効時区間を、時間に沿って伸びるバーとして示す。有効時区間の始端および終端における「Ｏ」および「Ｂ」の表記は、開始区分および終了区分がそれぞれオンラインおよびバッチであることを表す。また、それぞれのレコードについて、右側にキー（個人番号）および氏名が示されている。

まず、２００５年３月２７日２３：００の直後に、バッチ処理部５２が図５のフローチャートに従い、住居表示のためのバッチ処理に関するデータを読み込み、検索部４６に検索を指示する。ここではすべてのレコードを対象とするものとする。
検索部４６は、図９に示すように、ステップＳ７１でこの指示を受け取る。ステップＳ７２で、図２のレコードＲ１およびＲ２はいずれも有効であり、またステップＳ７３で、レコードＲ１およびＲ２はいずれも検索条件に適合すると判定される。同一キーのレコードが複数存在するものはないので、処理はステップＳ７４からステップＳ７８へと進み、レコードＲ１およびＲ２がバッチ処理部５２に渡される。バッチ処理部５２は、図５のステップＳ１３でレコードＲ１およびＲ２を受け取る。
ここで、データが大量であるためバッチ処理部５２の処理に時間がかかり、３月２８日になってもステップＳ１４が実行されていないとする。

３月２８日の１３：３０に、オンライン処理により、三菱太郎氏（キー：００１）の転居に伴う住所および学区の変更が入力されるとする。
図１２および図１３は、このオンライン処理が完了した時点、すなわち３月２８日の１３：００直後におけるデータテーブル２８の状態を示す。

この処理において、まずオンライン処理部５４が、図７のステップＳ３１でキーが００１であるという検索条件を受け取り、ステップＳ３２でこれを検索部４６に渡す。検索部４６は上記と同様にして、この条件に従って検索を行い、レコードＲ１を抽出し、これをオンライン処理部５４に渡す。オンライン処理部５４はこれから処理済レコードを作成し、これをオンライン更新部４４に渡す。
オンライン更新部４４は、抽出元レコードＲ１から満了レコードＲ１’を作成し、図８のステップＳ４７で抽出元レコードＲ１を満了レコードＲ１’で置き換える。さらに、処理済レコードから追加レコードＲ３を作成する。ここで、バッチ更新情報部２２（図３）が参照され、住居表示のバッチ処理が仕掛かり中であると判定されるため、追加レコードＲ３の終了時刻および終了区分が指定され、さらに処理済レコードから再追加レコードＲ４が作成される。ステップＳ５５で追加レコードＲ３および再追加レコードＲ４がデータテーブル２８に追加される。
ここで、満了レコードＲ１’は転居前の住所を含み、追加レコードＲ３は転居後かつ住居表示前の住所を含み、再追加レコードＲ４は住居表示後の住所を含む。

以上、図１２および図１３に示されるように、オンライン処理による更新の後では、その処理で更新または追加されたレコード（この場合はレコードＲ１’、Ｒ３、およびＲ４）の有効時区間は互いに重複しない。

その後、住居表示用のバッチ処理が進行して図５のステップＳ１４が実行され、上記で抽出されたレコードＲ１およびＲ２に対して住居表示処理がなされる。
図１４および図１５は、このバッチ処理が完了した時点におけるデータテーブル２８の状態を示す。

バッチ処理部５２は、図５のステップＳ１４でレコードＲ１およびＲ２に対してバッチ処理を行った後、すなわち住居表示のために住所を変更した後、これらをステップＳ１５でバッチ更新部４２に渡す。
バッチ更新部４２は、ステップＳ２１で処理済レコードを受け取る。ステップＳ２２で、レコードＲ１に対応する処理済レコードから追加レコードＲ６が、またレコードＲ２に対応する処理済レコードから追加レコードＲ８が、それぞれ作成される。
さらに、ステップＳ２３で、抽出元レコードであるレコードＲ１から満了レコードＲ５が、また同様にレコードＲ２から満了レコードＲ７が作成される。
このように作成されたレコードＲ５〜Ｒ８は、ステップＳ２４でデータテーブル２８に追加される。

ここで、満了レコードＲ５は転居前の住所を含み、追加レコードＲ６は転居前の住所に対して住居表示処理が行われたものを含む。すなわち、少なくとも三菱太郎氏の転居以降、レコードＲ５およびＲ６は正しくない内容を含むことになる。
また、満了レコードＲ７は住居表示前の住所を含み、追加レコードＲ８は住居表示後の住所を含む。

以上、図１４および図１５に示されるように、バッチ処理による更新の後では、その処理で追加されたレコード（この場合は、レコードＲ１に対してレコードＲ５およびＲ６、レコードＲ２に対してレコードＲ７およびＲ８）の有効時区間は互いに重複する。

ここで、３月２９日の１０：００に、オンライン処理によって、三菱太郎氏（キー：００１）および鎌倉次郎氏のレコード（キー：００２）が検索されたとする。以下、オンライン処理部５４およびオンライン更新部４４の処理は説明を省略し、検索部４６の処理のみ説明する。

まず、三菱太郎氏（キー：００１）に対する処理を説明する。検索部４６は、上述の３月２８日１３：３０のオンライン処理と同様にして、図９のステップＳ７１でキーが００１であるという検索条件を受け取る。
ステップＳ７２で、当該時刻において有効なレコードとして、図１５に示すように、キー００１を有するレコードＲ３およびＲ５と、キー００２を有するレコードＲ２およびＲ７とが抽出される。ステップＳ７３で、これらのレコードのうちから、検索条件に適合するキー００１を有するレコードＲ３およびＲ５のみが抽出される。

ステップＳ７４で同一のキー００１を有するレコードが複数あるので、処理はステップＳ７５に進み、開始時刻が最新であるレコードＲ３が優先されて選択される。ここにおいて選択されるレコードはレコードＲ３のみとなるので、処理はステップＳ７６からＳ７８へと進み、レコードＲ３が抽出済レコードとなる。このようにして、転居前の正しくない内容を含むレコードＲ５の抽出は避けられる。

次に、鎌倉次郎氏（キー：００２）に対する処理を説明する。検索部４６は、上記と同様に、ステップＳ７１でキーが００２であるという検索条件を受け取る。
ステップＳ７２で、上記と同様にレコードＲ２、Ｒ３、Ｒ５、およびＲ７が抽出される。ステップＳ７３で、これらのレコードのうちから、検索条件に適合するキー００２を有するレコードＲ２およびＲ７のみが抽出される。

ステップＳ７４で同一のキー００２を有するレコードが複数あるので、処理はステップＳ７５に進む。レコードＲ２およびＲ７の開始時刻は等しいので、開始時刻が最新のレコードとしてこれらの両方が選択され、処理はステップＳ７７へと進む。ステップＳ７７では、住居表示のバッチ処理が仕掛かり中なので、図１０の表（ａ）によって優先順位が決定され、レコードＲ２の優先順位は１となり、レコードＲ７の優先順位は２となる。この結果、レコードＲ２が選択され、これが抽出済レコードとなる。このようにして、更新反映時刻前の内容を含むレコードＲ７の抽出は避けられる。

なお、この例はバッチ処理の仕掛かり中に検索を行った場合のものである。バッチ処理の仕掛かり中でない場合の例として、たとえば４月２日以降に、過去データとしての３月２９日１０：００時点のレコードの検索を行った場合は、図１０の表（ｂ）が使用されるので、レコードＲ２の優先順位は３となり、レコードＲ７の優先順位は２となる。この結果、仕掛かり中の場合とは異なり、レコードＲ７、すなわちすでに完了したバッチ処理による終了区分が指定されたものが選択されることになる。

また、図示しないが、たとえば４月２日以降に、その時点で有効なデータの検索を行った場合、キー００１に対しては開始区分がオンラインであるレコードＲ４が選択され、転居前の正しくない情報を含むレコードＲ６の抽出は避けられる。また、キー００２に対しては開始時刻が最新であるレコードＲ８が選択され、住居表示が行われていないレコードＲ２の抽出は避けられる。

以上説明されるように、本発明に係るデータベースサーバ１は、バッチ処理の際には、ロックをかけて既存のレコードを更新する代わりに、ロックをかけずに既存のレコードと同一のキーおよび重複する有効時区間を有するレコードを追加する。ここで、バッチ処理はロックを伴わないので、これが仕掛かり中であっても、ロックを伴うオンライン処理を並列して実行することができる。
そして、検索の際に、同一のキーを有する有効なレコードが複数存在する場合は、それらのレコードの間の優先順位に基づいて抽出するレコードを選択することで、その時点で不適切なデータを含むレコードが抽出されることを防ぎ、データの整合性を保持する。
このようにして、データベースサーバ１は、時制データベースにおいて、バッチ処理とオンライン処理とを同時に実行することができる。

上述の実施の形態１において、データベースサーバ１は、データベースシステムの全体を含む。すなわち、バッチ更新情報部２２、オンライン更新情報部２４、データ格納部２６、バッチ更新部４２、オンライン更新部４４、検索部４６、入出力部４８、バッチ処理部５２、および、オンライン処理部５４は、すべて単一のコンピュータに含まれる。
これとは異なる実施形態として、これらが複数のコンピュータに分散して設けられてもよい。たとえば、バッチ処理部５２とオンライン処理部５４とがそれぞれ独立したコンピュータに設けられてもよい。

また、上述の実施の形態１において、データテーブル２８は、各レコードについて、有効時区間の終了時刻を含まないものであってもよい。すなわち、キーおよび属性情報、開始時刻、開始区分、および終了区分のみを含むものであってもよい。この場合、終了時刻は、すべてのレコードについて同一であるとして扱われてもよい。こうすることにより、扱うべきフィールド数およびデータ量を削減することができる。
なお、優先順位の決定には終了時刻は用いられていないため、この場合であっても実施の形態１と同様の処理を適用することができる。

また、上述の実施の形態１において、転出等によって個人情報が削除される場合には、たとえば対応するレコードの氏名および住所を空白とすることによって示される。これとは異なる実施形態として、特定のキーに対応するデータの削除を示す削除レコードが、追加レコードあるいは再追加レコードの代わりに追加されるものであってもよい。こうすることにより、削除されたデータをより容易かつ明確に区別することができる。

また、上述の実施の形態１においては、既存レコードの更新および新規レコードの追加は行われるが、不要となった既存レコードの削除は行われない。これとは異なる実施形態として、データベースサーバ１は、一定の条件を満たすレコードを、不要と判断してデータテーブル２８から削除する、削除部としての機能を有してもよい。この削除部は、たとえばオンライン更新部４４に含まれるものであってもよく、その他の構成要素に含まれるものであってもよく、また独立した構成要素であってもよい。データを不要と判断する条件としては、検索の際に選択される可能性のないレコード、すなわち常に優先順位が２番目以降となるレコードが該当するような条件が用いられる。この削除は定期的に行われてもよく、外部からの指示に応じて行われてもよい。なお、この削除は、レコードを無効とする処理とは異なり、そのレコード自体を実際にデータテーブル２８から抹消するものである。
このようにすることにより、不要なレコードが削除されるので、データ格納部２６の記憶容量が節約できる。また、有効なレコードの数が少なくなるので、レコード間の優先順位を決定するために要求される検索部４６の処理能力を小さくすることができる。

実施の形態２．
実施の形態２は、上述の実施の形態１において、図８のステップＳ５０における分岐条件を変更し、かつ、図９のステップＳ７５における選択に用いられる基準を変更するものである。
実施の形態１では、図８のステップＳ５０において、仕掛かりバッチ処理の有無のみが判定されるが、実施の形態２では、仕掛かりバッチ処理の有無に加え、追加レコードがその仕掛かりバッチ処理の対象となるかどうかが判定される。仕掛かりバッチ処理が存在し、かつ追加レコードがその対象となる場合のみ処理はステップＳ５２に進み、そうでない場合はステップＳ５１に進む。
また、実施の形態１では、図９のステップＳ７５において、レコードの開始時刻が基準として用いられるが、実施の形態２では、開始時刻そのものではなく、開始時刻が属する時間帯が基準として用いられる。この時間帯は、各バッチ処理の更新反映時刻によって区画される。すなわち、（あるバッチ処理の更新反映時刻）＜（レコードＸの開始時刻）≦（次のバッチ処理の更新反映時刻）となる条件に適合するレコードＸは、ステップＳ７５での選択においてはすべて等価なものとして扱われることになる。これが実施の形態２における第一の選択となる。
その他の部分については、実施の形態１と同様であるので、説明を省略する。

図１６および図１７は、実施の形態２における処理の流れを説明する図である。なお、ここでは、実施の形態１の図１１、図１３、および図１５と同様に、各レコードの開始時刻、終了時刻、開始区分、終了区分のみを示す。
図１６に示すように、あるバッチ処理Ａの更新反映時刻ＴＡより後に、レコードＸ１に対してバッチ処理Ｂが実行され、満了レコードＸ２および追加レコードＸ３が追加されている。

図１７は、バッチ処理Ｂの更新反映時刻ＴＢより前の時刻ＴＣに、レコードＸ１に対するオンライン処理Ｃが発生した場合の処理結果を示す。図８のステップＳ４８で、レコードＸ１に対応する満了レコードＸ１’および追加レコードＸ４が作成される。ここで、オンライン処理Ｃによって変更された結果として、追加レコードＸ４がバッチ処理Ｂの処理対象から外れる場合を考える。ステップＳ５０で、仕掛かりバッチ処理としてバッチ処理Ｂが存在するが、追加レコードＸ４はその対象ではないので、処理はステップＳ５１に進み、再追加レコードは作成されない。
なお、このような状況が発生する具体例としては、住居表示用バッチ処理の対象であった個人が、レコード抽出時刻の後、更新反映時刻の前に、住居表示対象外の区域に転居した場合等が考えられる。このような場合、時刻ＴＣ以降の正しいデータを含むレコードは、レコードＸ３ではなくレコードＸ４となる。

ここで、時刻ＴＢより後に検索が実行されるとする。有効なレコードはレコードＸ３およびＸ４であるが、（バッチ処理Ａの更新反映時刻ＴＡ）＜（そのレコードの開始時刻）≦（バッチ処理Ｂの更新反映時刻ＴＢ）という不等式は、レコードＸ３およびＸ４の両方について成立するため、ステップＳ７５の選択では、レコードＸ３およびＸ４は等価であると判定され、両方が選択される。その後、ステップＳ７７で、図１０の表（ｂ）に基づき、正しいデータを含むレコードＸ４が優先されて選択される。

このように、実施の形態２では、レコード間の優先順位を決定する際の基準として、レコードの開始時刻ではなく、開始時刻が属する時間帯を基準とする。このため、バッチ処理が仕掛かり中となっているレコードが、オンライン処理によって当該バッチ処理の対象外となる場合が発生し得るようなデータテーブル２８に対しても、データの整合性を保持することができる。

なお、本明細書において、「オンライン処理」および「バッチ処理」という用語は、必ずしも一般的な意味を有するものではなく、それぞれ、ロックを伴う処理、およびロックを伴わない処理として解釈される。すなわち、なんらかの定義において「オンライン処理」と呼び得る処理であっても、ロックを伴わずに実行される処理は、本明細書におけるバッチ処理として解釈される。また逆も同様である。

本発明の実施の形態１に係るデータベースサーバ１を含む構成を示す図である。 図１のデータテーブル２８の構成を示す図である。 図１のバッチ更新情報部２２に格納されるデータの構成を示す図である。 図１のオンライン更新情報部２４に格納されるデータの構成を示す図である。 図１のバッチ処理部５２の処理の流れを示すフローチャートである。 図１のバッチ更新部４２の処理の流れを示すフローチャートである。 図１のオンライン処理部５４の処理の流れを示すフローチャートである。 図１のオンライン更新部４４の処理の流れを示すフローチャートである。 図１の検索部４６の処理の流れを示すフローチャートである。 図９のステップＳ７７における選択の際の、優先順位の決定方法を示す図である。 図２の各レコードを模式的に示す図である。 図１のデータテーブル２８の、処理の一段階における内容を示す。 図１２の各レコードを模式的に示す図である。 図１のデータテーブル２８の、処理の一段階における内容を示す。 図１４の各レコードを模式的に示す図である。 本発明の実施の形態２に係るデータベースサーバの処理の流れを説明する図である。 本発明の実施の形態２に係るデータベースサーバの処理の流れを説明する図である。

符号の説明

１ データベースサーバ（データベースシステム）、２８ データテーブル（データベース）、４２ バッチ更新部（第一更新部）、４４ オンライン更新部（第二更新部）、４６ 検索部、Ｒ１〜Ｒ８、Ｒ１’ レコード（Ｒ３、Ｒ６、Ｒ８ 追加レコード）、Ｘ１〜Ｘ４、Ｘ１’ レコード（Ｘ３、Ｘ４ 追加レコード）。

Claims (15)

1. データベースに関する処理を行うデータベースシステムであって、
   前記データベースは、複数のレコードを含み、
   前記データベースは、前記レコードが、時間の経過につれて無効から有効となるデータと、そのデータが有効である有効時区間を表す情報と、検索に用いられるキーとを有する、時制データベースであり、
   前記処理の少なくとも一部は第一種の処理であり、
   前記第一種の処理は、前記第一種の処理の対象となるレコードに関連して、前記第一種の処理のそれぞれに関連付けられた時刻において、有効な前記データを変更するものであり、
   前記データベースシステムは、
   前記第一種の処理に関連して、前記第一種の処理の対象となるレコードの前記キーと同一のキーを有する追加レコードを作成して前記時制データベースに追加する、第一更新部と、
   前記キーを含む検索条件を受け取るとともに、この検索条件に適合するレコードを前記時制データベースから抽出する、検索部と
   を備え、
   前記第一更新部は、前記追加レコードの有効時区間の開始時刻を、前記第一種の処理に関連付けられた前記時刻に基づいて指定し、それによって、前記追加レコードの有効時区間を、前記第一種の処理の対象となるレコードの有効時区間と少なくとも一部が重複するものとし、
   前記検索部は、前記検索条件に適合するレコードが複数存在する場合、所定の基準に基づいて一つのレコードを選択する
   データベースシステム。
2. 前記データの少なくとも一部は、さらに、時間の経過につれて有効から無効となるものであり、
   前記第一種の処理に関連するレコードの有効時区間の終了時刻が、前記第一種の処理に関連付けられた前記時刻に基づいて指定される
   請求項１に記載のデータベースシステム。
3. 前記第一種の処理はバッチ処理であり、
   前記第一更新部は、前記対象となるレコードに対する排他制御を行わない
   請求項１または２に記載のデータベースシステム。
4. 前記所定の基準は前記有効時区間に関連する、請求項１〜３のいずれか一項に記載のデータベースシステム。
5. 前記所定の基準は、前記有効時区間について最も新しい開始時刻を有するレコードを選択する、第一の選択を行うという基準を含む、請求項４に記載のデータベースシステム。
6. 前記所定の基準は、前記有効時区間について、最も新しい時間帯に属する開始時刻を有するレコードを選択する、第一の選択を行うという基準を含み、
   前記時間帯は、順に実行される２つの前記第一種の処理について、それぞれに関連付けられた前記時刻によって区画されるものである
   請求項４に記載のデータベースシステム。
7. 前記処理の少なくとも一部は、前記第一種の処理とは異なる第二種の処理であり、
   前記データベースシステムは、さらに、前記第二種の処理に関連するレコードの、前記有効時区間の開始時刻を指定する、第二更新部を備える
   請求項１〜６のいずれか一項に記載のデータベースシステム。
8. 前記第二更新部は、さらに、前記第二種の処理に関連するレコードの、前記有効時区間の終了時刻を指定する、請求項２に記載のデータベースシステムであって、請求項７に記載のデータベースシステム。
9. 前記レコードは、さらに、前記有効時区間の開始時刻および終了時刻が、それぞれ、前記第一更新部および前記第二更新部のいずれによって指定されたものであるかを示す、開始区分および終了区分を表す情報を含み、
   前記所定の基準は、前記開始区分および前記終了区分に関連する
   請求項８に記載のデータベースシステム。
10. 前記第二種の処理は、その処理の対象となるレコードに基づいて追加レコードを作成する処理を含むものであり、
    前記第二種の処理が、前記第一種の処理に関連付けられた時刻より前に実行される場合は、その第二種の処理において作成される前記追加レコードに対し、その第一種の処理を実行する
    請求項７〜９のいずれか一項に記載のデータベースシステム。
11. 前記第二種の処理はオンライン処理であり、
    前記第二更新部は、前記対象となるレコードに対する排他制御を行う
    請求項７〜１０のいずれか一項に記載のデータベースシステム。
12. 前記所定の基準は、さらに、
    第一の選択によって複数のレコードが選択された場合は、前記開始区分が前記第二更新部を示すレコードを優先して選択する、第二の選択を行う
    という基準を含む、請求項５または６に記載のデータベースシステムであって、かつ請求項９に記載のデータベースシステム。
13. 前記検索条件は、前記検索が実行される検索実行時刻を含み、
    前記所定の基準は、さらに、
    前記第二の選択によって複数のレコードが選択された場合は、前記終了時刻と、前記検索実行時刻とを比較し、
    前記終了時刻が前記検索実行時刻より新しい場合には、前記終了区分が前記第二更新部を示すか、または前記終了区分が前記第一更新部および前記第二更新部のいずれも示さないレコードを優先して選択する、第三の選択を行い、
    前記終了時刻が前記検索実行時刻より古い場合には、前記終了区分が前記第二更新部を示すレコード、前記終了区分が前記第一更新部を示すレコード、および、前記終了区分が前記第一更新部および前記第二更新部のいずれも示さないレコードの順に優先して選択する、第四の選択を行う
    という基準を含む、請求項１２に記載のデータベースシステム。
14. 前記複数のレコードのうち少なくとも一部のレコードは削除レコードであって、
    前記複数のレコードのうち、前記削除レコードと同一のキーを有するレコードはすべて無効である
    請求項１〜１３のいずれか一項に記載のデータベースシステム。
15. 前記データベースシステムは、さらに、前記所定の基準に基づく選択において選択される可能性のないレコードの少なくとも１つを、前記時制データベースから削除する、削除部を備える、請求項１〜１４のいずれか一項に記載のデータベースシステム。

Images