JP2017097639A

JP2017097639A - データベース制御プログラム、データベース制御装置及びデータベース制御方法

Info

Publication number: JP2017097639A
Application number: JP2015229507A
Authority: JP
Inventors: 敏郎小野; Toshiro Ono
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2015-11-25
Filing date: 2015-11-25
Publication date: 2017-06-01

Abstract

【課題】データテーブルの参照中にインデックスの追加を行うことを可能にするデータベース制御プログラム、データベース制御装置及びデータベース制御方法を提供する。【解決手段】データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、インデックスの追加が完了するまでの間、データテーブルを全走査することによりデータテーブルに対するアクセスが行われるように、アクセスプランを作成し、インデックスの追加が完了した後、追加されたインデックスを参照してデータテーブルに対するアクセスが行われるように、アクセスプランを再作成する。【選択図】図７

Description

本発明は、データベース制御プログラム、データベース制御装置及びデータベース制御方法に関する。

利用者に対してサービスを提供する事業者（以下、単に事業者とも呼ぶ）は、利用者に対して各種サービスの提供を行うために、例えば、用途に応じた業務システムを構築して稼働させる。

具体的に、事業者は、上記のような業務システムを構築する際に、例えば、利用者に対してサービスを提供するために用いる情報（以下、データテーブルとも呼ぶ）を記憶するデータベース（ＤＢ：ＤａｔａＢａｓｅ）を利用する。また、事業者は、この場合、例えば、データベースに記憶された情報に対するアクセス要求の制御するためのデータベース管理システム（ＤＢＭＳ：ＤａｔａＢａｓｅＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ）を利用する。そして、事業者は、データベース内の記憶領域を効率的に使用するために、各情報のアクセス頻度やアクセスされる期間等を考慮した上で、データベース内における各情報の記憶位置を決定する（例えば、特許文献１、２参照）。

特開２００５−０１１０４８号公報特許第４５２２１７０号公報

上記のような業務システムにおいて、事業者は、例えば、テータベース内の記憶領域を予め複数の記憶領域に論理的に分割する（以下、論理的に分割された記憶領域をパーティションと呼ぶ）。そして、事業者は、例えば、利用者にサービスを提供するための情報を所定の規則に基づいてグループ分けし、それぞれ異なるパーティションに含まれる記憶領域（以下、表域とも呼ぶ）に記憶する。

具体的に、事業者は、例えば、利用者にサービスを提供するための情報について、利用者によってアクセスされる期間毎にグループ分けを行う。そして、事業者は、グループ分けされた情報を、それぞれ異なるパーティションに含まれる表域に記憶する。これにより、事業者は、例えば、アクセスされる期間が経過した情報の削除等を容易に行うことが可能になる。

また、上記のような業務システムにおいて、事業者は、例えば、パーティション毎にインデックスを作成する。インデックスは、例えば、頻繁にアクセスされる情報に対して迅速にアクセスを行うための情報である。

具体的に、事業者は、各パーティション内に含まれる記憶領域（例えば、表域以外の記憶領域）に、各表域に対応するインデックスを記憶する（以下、インデックスが記憶された記憶領域をインデックス領域とも呼ぶ）。そして、業務システムのＤＢＭＳは、アクセス要求を受け付けた場合に、参照可能なインデックスが存在するか否かを判定する。その結果、参照可能なインデックスが存在する場合、業務システムのＤＢＭＳは、そのインデックスを参照して、表域に記憶された情報に対するアクセスを行う。これにより、表域に記憶された情報に対するアクセスに要する時間を短縮させることが可能になる。

上記のようなインデックスの設定は、一般的に、データベースの設計内容等に基づき、業務システムの構築時において行われる。これに対し、業務システムのＤＢＭＳは、業務システムが利用者に提供するサービスの内容等によって、例えば、業務システムの設計時における事業者の想定を超えた大きさの表域の管理を行う場合がある。そのため、事業者は、データベースに対するアクセス性能の維持等を図るために、業務システムの稼働後においてもインデックスの追加を行う必要が生じる場合がある。

しかしながら、業務システムは、利用者に提供するサービスの内容によって、稼働後において停止することが困難である場合がある。そのため、事業者は、この場合、業務システムの稼働後におけるインデックスの追加を行うことが困難になる。

そこで、一つの側面では、データテーブルの参照中にインデックスの追加を行うことを可能にするデータベース制御プログラム、データベース制御装置及びデータベース制御方法を提供することを目的とする。

実施の形態の一つの態様によれば、コンピュータに、データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成し、前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成する、ことを実行させる。

一つの側面によれば、データテーブルの参照中にインデックスの追加を行うことを可能にする。

情報処理システム１０の全体構成を示す図である。アクセス要求が発生した場合の具体例を説明する図である。情報処理システム１０の稼働後にインデックスの追加を行う場合の具体例を説明する図である。情報処理システム１０の稼働後にインデックスの追加を行う場合の具体例を説明する図である。情報処理装置１のハードウエア構成を説明する図である。図５の情報処理装置１の機能ブロック図である。第１の実施の形態におけるＤＢ制御処理の概略を説明するフローチャートである。第１の実施の形態におけるＤＢ制御処理の概略を説明する図である。第１の実施の形態におけるＤＢ制御処理の概略を説明する図である。第１の実施の形態におけるＤＢ制御処理の概略を説明する図である。第１の実施の形態におけるＤＢ制御処理の概略を説明する図である。第１の実施の形態におけるＤＢ制御処理の詳細を説明するフローチャートである。第１の実施の形態におけるＤＢ制御処理の詳細を説明するフローチャートである。第１の実施の形態におけるＤＢ制御処理の詳細を説明するフローチャートである。第１の実施の形態におけるＤＢ制御処理の詳細を説明するフローチャートである。データテーブル１３２の具体例を説明する図である。データテーブル１３２の具体例を説明する図である。インデックス１３４の具体例を説明する図である。インデックス１３４の具体例を説明する図である。アクセスプラン１３１の具体例を説明する図である。状態情報１３５の具体例を説明する図である。インデックス１３４の具体例を説明する図である。インデックス１３４の具体例を説明する図である。判定情報１３３の具体例を説明する図である。判定情報１３３の具体例を説明する図である。インデックス１３４の追加が行われている場合におけるアクセスプラン１３１の具体例を説明する図である。インデックス１３４の追加が行われている場合におけるアクセスプラン１３１の具体例を説明する図である。インデックス１３４の追加が完了した場合におけるアクセスプラン１３１の具体例を説明する図である。インデックス１３４の追加が完了した場合におけるアクセスプラン１３１の具体例を説明する図である。インデックス１３４の追加が行われていない場合におけるアクセスプラン１３１の具体例を説明する図である。

［情報処理システムの構成］
図１は、情報処理システム１０の全体構成を示す図である。図１に示す情報処理システム１０（以下、業務システム１０とも呼ぶ）は、情報処理装置１と、データベース２とを有する。図１に示す情報処理装置１は、インターネット網等からなるネットワークＮＷを介して、利用者がサービスの提供を受けるために使用する利用者端末２１ａ、２１ｂ、２１ｃ（以下、これらを総称して利用者端末２１とも呼ぶ）とアクセス可能である。

情報処理装置１では、データベース２に記憶されている情報（事業者が利用者に対してサービスを提供するために用いる情報）を管理するＤＢＭＳが動作する。そして、情報処理装置１（情報処理装置１のＤＢＭＳ）は、利用者が利用者端末２１を介して送信したアクセス要求を受信した場合に、受信したアクセス要求の内容に基づいて、データベース２に記憶された情報に対するアクセスを行う。

なお、図１に示すデータベース２は、情報処理装置１の外部に存在している。これに対し、情報処理装置１に含まれる記憶媒体（図示しない）がデータベース２として機能するものであってもよい。以下、利用者が利用者端末２１を介して情報処理装置１にアクセス要求を送信した場合における処理について説明を行う。

［アクセス要求が発生した場合の具体例］
図２は、アクセス要求が発生した場合の具体例を説明する図である。以下、データベース２に記憶されている各情報は、予め定義された１つ以上の表（以下、データテーブルとも呼ぶ）であるものとする。

図２に示す例において、データベース２は、表１（表１に含まれる情報）を記憶している。そして、表１に含まれる情報は、所定の規則に基づいてグループ分けされ、データベース２内に確保された表域（１−１）、（１−２）及び（１−３）のいずれかに記憶されている。さらに、データベース２には、表域（１−１）、（１−２）及び（１−３）に記憶された情報にそれぞれ対応するインデックス（１−１）、（１−２）及び（１−３）が記憶されている。

初めに、利用者は、図２に示すように、情報処理装置１に対するアクセス要求を作成する。このアクセス要求は、例えば、利用者が利用者端末２１においてＳＱＬ（ＳｔｒｕｃｔｕｒｅｄＱｕｅｒｙＬａｎｇｕａｇｅ）文を入力することによって作成される。具体的に、利用者は、例えば、図２に示すように、データベース２に記憶されている表１に含まれる情報のうち、Ｃ２０に設定された値が１よりも大きい情報の全ての項目を抽出するためのアクセス要求である「ＳＥＬＥＣＴ＊ＦＲＯＭ表１ＷＨＥＲＥＣ２０＞１；」を作成する。そして、利用者は、図２に示すように、作成したアクセス要求を情報処理装置１に送信する。

次に、情報処理装置１は、利用者（利用者端末２１）からアクセス要求を受信した場合、例えば、情報処理装置１内の記憶部１３０を参照し、受信したアクセス要求に対応するアクセスプラン１３１が存在するか否かを判定する。アクセスプラン１３１は、データベース２に記憶されている情報に対するアクセス経路が定義された情報である。

そして、情報処理装置１は、受信したアクセス要求に対応するアクセスプラン１３１が記憶部１３０に存在する場合、存在したアクセスプラン１３１の内容に基づいて、アクセス要求に対応する情報（データベース２に記憶された情報）に対してアクセスを行う。具体的に、情報処理装置１は、図２に示すように、インデックス（１−２）を経由すべき旨の情報がアクセスプラン１３１に含まれている場合、インデックス（１−２）を経由して、表域（１−２）に記憶された情報に対してアクセスを行う。また、情報処理装置１は、インデックスを経由しない旨の情報がアクセスプラン１３１に含まれている場合、アクセス要求に対応する情報が存在する可能性がある全領域（表域（１−１）、（１−２）及び（１−３））を走査し、アクセスすべき情報に対してアクセスを行う。

一方、情報処理装置１は、受信したアクセス要求に対応するアクセスプラン１３１が記憶部１３０に存在しない場合、例えば、事業者が予め設定したポリシーに基づき、受信したアクセス要求に対応するアクセスプラン１３１を新たに作成する。このポリシーは、例えば、情報に対してアクセスを行う際に経由することができるインデックスが存在する場合、必ずそのインデックスを経由してアクセスプラン１３１を作成する旨を含むものであってよい。そして、情報処理装置１は、作成したアクセスプラン１３１の内容に基づいて、アクセス要求に対応する情報（データベース２に記憶された情報）に対してアクセスを行う。その後、情報処理装置１は、新たに作成したアクセスプラン１３１を記憶部１３０に記憶する。

これにより、情報処理装置１は、記憶部１３０にアクセスプラン１３１が記憶されているアクセス要求を受信した場合、新たなアクセスプラン１３１の作成を行う必要がないため、アクセスに要する時間を短縮することが可能になる。

［情報処理システムの稼働後にインデックスの追加を行う場合の具体例］
次に、情報処理システム１０の稼働後にインデックスの追加を行う場合の具体例について説明を行う。図３及び図４は、情報処理システム１０の稼働後にインデックスの追加を行う場合の具体例を説明する図である。以下、表２に含まれる情報が表域（２−１）及び（２−２）にも記憶されることに伴い、表域（２−１）及び（２−２）にそれぞれ対応するインデックス（２−１）及び（２−２）が新たに作成（追加）される場合について説明を行う。

一般的に、インデックスの作成は、情報処理システム１０の構築前に行われたデータベースの設計内容に基づき、情報処理システム１０の構築時において行われる。これに対し、情報処理装置１は、情報処理システム１０が利用者に提供するサービスの内容等によって、業務システムの設計時における事業者の想定を超えた大きさの表域の管理を行う場合がある。そのため、事業者は、データベースに対するアクセス性能の維持等を図るために、インデックスの追加を情報処理システム１０の稼働後において行う場合がある。

しかしながら、情報処理システム１０は、利用者に提供するサービスの内容等によって、稼働後において停止することが困難である場合がある。そのため、事業者は、インデックスの追加を行うために、例えば、稼働中の情報処理システム１０を停止することなくインデックスの追加を行う。すなわち、情報処理装置１は、この場合、図３及び図４に示すように、利用者端末２１が送信したアクセス要求に対応する処理と並行しながらインデックスの追加に伴う処理を実行する。

具体的に、図３に示す例では、インデックス（２−１）及び（２−２）を記憶するためのインデックス領域の確保が完了し、インデックス（２−１）の記憶についても完了している状態を示している。一方、図３に示す例では、インデックス（２−２）の記憶については完了していない状態を示している。すなわち、利用者端末２１が送信したアクセス要求に対応する処理と並行してインデックスの追加を行う場合、情報処理装置１は、図３に示すような場合においても、利用者端末２１から受信したアクセス要求の内容に基づいてデータベース２に対するアクセスを行う。

ここで、情報処理装置１（情報処理装置１のＤＢＭＳ）は、インデックス領域が確保されているインデックスの経由を許可するか否かについて、データベース２に記憶されている表毎にのみ制御を行う場合がある。そして、図３に示す例では、表２のインデックスであるインデックス（２−１）及び（２−２）のインデックス領域が既に確保されている状態である。そのため、情報処理装置１は、この場合、インデックス領域に対するインデックス（２−２）の記憶が完了しているか否かを問わず、インデックス（２−２）を経由する場合を含むアクセスプラン１３１を作成する。したがって、インデックス（２−２）を経由すべきアクセス要求が発生した場合、情報処理装置１は、図４に示すように、インデックス（２−２）を経由したアクセスを試みることになる。

しかしながら、この場合、インデックス領域に対するインデックス（２−２）の追加が完了していないため、受信したアクセス要求の内容に基づくデータベース２（表域（２−２））に対するアクセスは失敗する。

そこで、本実施の形態における情報処理装置１は、データベース２に記憶されたデータテーブルについてのインデックスの追加が発生したときに、データテーブルを全走査することによりデータテーブルに対するアクセスが行われるように、アクセスプランを作成する。そして、情報処理装置１は、インデックスの追加が完了した後、追加されたインデックスを参照してデータテーブルに対するアクセスが行われるように、アクセスプランを再作成する。

すなわち、情報処理装置１は、インデックスの追加（図３及び図４の例ではインデックス（２−１）及び（２−２））が行われている間、その追加されているインデックスを参照することなくデータテーブルにアクセスを行うように、アクセスプランを作成する。具体的に、情報処理装置１は、インデックスの追加が行われている間、データテーブルの全走査を行うことによってデータテーブルへのアクセスを行うように、アクセスプランの作成を行う。これにより、情報処理装置１は、インデックスの追加が行われている間であっても、データテーブルに対するアクセスの失敗の発生を防止することが可能になる。

［情報処理装置のハードウエア構成］
次に、情報処理装置１のハードウエア構成について説明する。図５は、情報処理装置１のハードウエア構成を説明する図である。

情報処理装置１は、プロセッサであるＣＰＵ１０１と、メモリ１０２と、外部インターフェース（Ｉ／Ｏユニット）１０３と、記憶媒体（ストレージ）１０４とを有する。各部は、バス１０５を介して互いに接続される。

記憶媒体１０４は、記憶媒体１０４内のプログラム格納領域（図示しない）に、データベース２のアクセス制御を行う処理（以下、ＤＢ制御処理とも呼ぶ）を行うためのプログラム１１０（以下、ＤＢ制御プログラム１１０とも呼ぶ）を記憶する。

ＣＰＵ１０１は、図５に示すように、プログラム１１０の実行時に、プログラム１１０を記憶媒体１０４からメモリ１０２にロードし、プログラム１１０と協働してＤＢ制御処理を行う。

外部インターフェース１０３は、データベース２と通信を行う。また、外部インターフェース１０３は、ネットワークＮＷを介して利用者端末２１と通信を行う。

また、記憶媒体１０４は、例えば、ＤＢ制御処理を行う際に用いられる情報を記憶する情報格納領域１３０（以下、記憶部１３０とも呼ぶ）を有する。なお、以下、図１等で説明したデータベース２は、情報格納領域１３０の一部であるものとして説明を行う。

[情報処理装置のソフトウエア構成]
次に、情報処理装置１のソフトウエア構成について説明する。図６は、図５の情報処理装置１の機能ブロック図である。ＣＰＵ１０１は、プログラム１１０と協働することにより、アクセスプラン作成部１１１と、情報管理部１１２と、アクセス実行部１１３と、アクセスプラン再作成部１１４と、インデックス管理部１１５として動作する。また、情報格納領域１３０には、アクセスプラン１３１と、データテーブル１３２と、判定情報１３３と、インデックス１３４と、状態情報１３５とが記憶されている。

アクセスプラン作成部１１１は、利用者端末２からデータベース２に記憶されたデータテーブル１３２に対するアクセス要求を受信した場合に、そのアクセス要求に対応するアクセスプラン１３１を作成する。そして、アクセスプラン作成部１１１は、作成したアクセスプラン１３１を情報格納領域１３０に記憶する。なお、アクセスプラン作成部１１１は、受信したアクセス要求に対応するアクセスプラン１３１が記憶部１３０に既に存在する場合、新たなアクセスプラン１３１の作成を行わず、存在したアクセスプラン１３１を維持するものであってよい。すなわち、アクセスプラン作成部１１１は、受信したアクセス要求に対応するアクセスプラン１３１が存在しない場合に、新たなアクセスプラン１３１を作成するものであってよい。

また、アクセスプラン作成部１１１は、インデックス１３４の追加が行われている間、データテーブル１３２へのアクセスがデータテーブル１３２（アクセスすべき情報が存在する可能性がある全てのデータテーブル１３２）を全走査することにより行われるように、アクセスプラン１３１を作成する。そして、アクセスプラン作成部１１１は、作成したアクセスプラン１３１を情報格納領域１３０に記憶する。なお、アクセスプラン作成部１１１は、インデックス１３４の追加が行われている場合においても、インデックス１３４の追加が行われる前に作成されたアクセスプラン１３１が既に存在する場合、新たなアクセスプラン１３１を作成せずに、存在したアクセスプラン１３１を維持するものであってよい。アクセスプラン１３１の具体例については後述する。

情報管理部１１２は、インデックス１３４の追加が現在行われているか否かを示す判定情報１３３の更新を行う。また、情報管理部１１２は、インデックス１３４の追加が完了したか否かを示すパーティション毎（インデックス１３４毎）の状態情報１３５の更新を行う。判定情報１３３及び状態情報１３５の具体例については後述する。

アクセス実行部１１３は、利用者端末２１からデータベース２に記憶された情報に対するアクセス要求を受信した場合に、情報格納領域１３０に記憶されたアクセスプラン１３１（新たに作成されたアクセスプラン１３１を含む）を参照して、データベース２に記憶された情報に対するアクセスを行う。そして、アクセス実行部１１３は、アクセスを行った結果を利用者端末２に送信する。

アクセスプラン再作成部１１４は、インデックス１３４の追加が完了した後、追加されたインデックス１３４を参照してデータテーブルに対するアクセスが行われるように、アクセスプラン１３１を再作成する。すなわち、アクセスプラン再作成部１１４は、この場合、例えば、追加されたインデックス１３４に対応するデータテーブル１３２にアクセスするための全てのアクセスプラン１３１を再作成する。

なお、アクセスプラン再作成部１１４は、インデックス１３４の追加が完了した場合、追加されたインデックス１３４に対応するデータテーブル１３２にアクセスするための全てのアクセスプラン１３１の削除を行うものであってもよい。この場合、アクセスプラン作成部１１１は、受信したアクセス要求に対応するアクセスプラン１３１が存在しない場合に、アクセスプラン再作成部１１４が削除したアクセスプラン１３１を含め、追加されたインデックス１３４を参照する場合を含むアクセスプラン１３１の作成を行う。

また、データテーブル１３２が複数の表域に分割されて記憶されている場合、追加されるインデックス１３４は、その複数の表域に含まれる１以上の表域それぞれに対応する１以上のインデックス１３４である。この場合、アクセスプラン再作成部１１４は、その１以上のインデックス１３４の全ての追加が完了した場合に、アクセスプラン１３１の再作成（アクセスプラン１３１の削除）を行うものであってよい。

インデックス管理部１１５は、事業者等によるインデックス１３４の追加要求（以下、単にインデックス追加要求とも呼ぶ）を受信した場合、インデックス１３４の作成を行う。そして、インデックス管理部１１５は、作成したインデックス１３４を情報格納領域１３０に記憶する。インデックス１３４の具体例については後述する。

[第１の実施の形態の概略］
次に、第１の実施の形態の概略について説明する。図７は、第１の実施の形態におけるＤＢ制御処理の概略を説明するフローチャートである。また、図８から図１１は、第１の実施の形態におけるＤＢ制御処理の概略を説明する図である。図８から図１１を参照しながら、図７のＤＢ制御処理について説明を行う。なお、図８から図１１に示すデータベース２は、図３及び図４で説明したデータベース２に対応する。また、図８から図１１において、インデックス（１−１）から（１−３）、及び表域（１−１）から（１−３）については図示しない。

[ＤＢ制御処理の概略］
情報処理装置１は、図７に示すように、インデックス１３４の追加が発生するまで待機する（Ｓ１のＮＯ）。具体的に、情報処理装置１は、例えば、事業者がインデックス１３４の追加を行う旨の入力を行うまで待機する。そして、インデックス１３４の追加が発生した後（Ｓ１のＹＥＳ）、情報処理装置１は、図８に示すように、インデックス１３４を参照せずにデータテーブル１３２を全走査することによりデータテーブル１３２にアクセスするように、アクセスプラン１３１を作成する（Ｓ２）。

すなわち、情報処理装置１は、インデックス１３４の追加が行われている間において、データテーブル１３２に対するアクセス要求を受信した場合、図９に示すように、既に追加設定が完了したインデックス１３４（インデックス（２−１））についても参照せずに、データテーブル１３２（表域（２−１）及び（２−２））に対するアクセスを行う。これにより、情報処理装置１は、受信したアクセス要求に対応するアクセスを行った際に、インデックス１３４（インデックス１３４の一部）の追加がまだ完了していないことに伴うアクセス失敗の発生を防止することが可能になる。

具体的に、情報処理装置１は、例えば、インデックス１３４の追加が行われている間に発生したアクセス要求に対応するアクセスプラン１３１が情報格納領域１３０に記憶されている場合、記憶されていたアクセスプラン１３１を、データテーブル１３２を全走査することによりアクセスするように更新する。一方、情報処理装置１は、例えば、インデックス１３４の追加が行われている間に発生したアクセス要求に対応するアクセスプラン１３１が情報格納領域１３０に記憶されていない場合、データテーブル１３２を全走査してアクセスするようにアクセスプラン１３１を新たに作成する（Ｓ２）。

図７に戻り、情報処理装置１は、インデックス１３４の追加が完了するまで待機する（Ｓ３のＮＯ）。具体的に、情報処理装置１は、例えば、事業者がインデックス１３４の追加が完了した旨の入力を行うまで待機する。その後、インデックス１３４の追加が完了した場合（Ｓ３のＹＥＳ）、情報処理装置１は、図１０に示すように、追加されたインデックス１３４を参照してデータテーブル１３２に対するアクセスを行うように、アクセスプラン１３１を再作成する。

すなわち、インデックス１３４の追加が完了した場合、情報処理装置１は、アクセスの失敗を発生させることなく、インデックス１３４を参照してデータテーブル１３２のアクセスを行うことが可能になる。そのため、情報処理装置１は、この場合、図１１に示すように、作成済のインデックス１３４（新たに追加されたインデックス１３４を含む）を参照してデータテーブル１３２へのアクセスを行うように、アクセスプラン１３１の再作成を行う。

具体的に、情報処理装置１は、データテーブル１３２を全走査するように作成したアクセスプラン１３１を、インデックス１３４（追加されたインデックス１３４を含む）を参照してデータテーブル１３２に対するアクセスを行うように再作成する（Ｓ４）。

このように、情報処理装置１は、データベース２に記憶されたデータテーブル１３２についてのインデックス１３４の追加が発生したときに、アクセスプラン１３１の作成を行う。具体的に、情報処理装置１は、この場合、インデックス１３４の追加が完了するまでの間、インデックス１３４を参照せずにデータテーブル１３２を全走査することによりデータテーブル１３２に対するアクセスが行われるように、アクセスプラン１３１を作成する。

その後、情報処理装置１は、インデックス１３４の追加が完了した後、追加されたインデックス１３４を参照してデータテーブル１３２に対するアクセスが行われるように、アクセスプラン１３１を再作成する。

これにより、情報処理装置１は、インデックス１３４の追加が行われている場合であっても、アクセス失敗を発生させることなく、データテーブル１３２に対するアクセスを行うことが可能になる。そのため、情報処理装置１は、データテーブルの参照中にインデックスの追加を行うことが可能になる。

[第１の実施の形態の詳細]
次に、第１の実施の形態の詳細について説明する。図１２から図１５は、第１の実施の形態におけるＤＢ制御処理の詳細を説明するフローチャートである。また、図１６から図３０は、第１の実施の形態におけるＤＢ制御処理の詳細を説明する図である。図１６から図３０を参照しながら、図１２から図１５のＤＢ制御処理を説明する。

[データテーブル、インデックス及びアクセスプラン]
初めに、データテーブル１３２、インデックス１３４及びアクセスプラン１３１の具体例について説明を行う。以下、データテーブル１３２は、データテーブル１３２ａとデータテーブル１３２ｂとに分割され、データベース２内における異なる表域にそれぞれ記憶されているものとして説明を行う。また、以下、データテーブル１３２は、事業者が提供するサービスを利用する利用者の情報を含む利用者表であるものとして説明を行う。

[データテーブルの具体例]
図１６及び図１７は、データテーブル１３２の具体例を説明する図である。図１６は、データテーブル１３２ａの具体例であり、図１７は、データテーブル１３２ｂの具体例である。

図１６に示すデータテーブル１３２ａには、データテーブル１３２ａに含まれる各情報を識別する「項番」と、データテーブル１３２ａに含まれる各情報がデータベース２に記憶された日を示す「登録日」とを項目として有している。また、図１６に示すデータテーブル１３２ａには、記憶された情報のうちの氏名が設定される「氏名」と、記憶された情報のうちの所在地が設定される「所在地」と、記憶された情報のうちの年齢が設定される「年齢」とを項目として有する。

具体的に、図１６に示すデータテーブル１３２ａにおいて、「項番」が「１」である情報には、「登録日」として「２０１４／８／２」が設定され、「氏名」として「ＡＡＡ」が設定され、「所在地」として「東京」が設定され、「年齢」として「３２」が設定されている。図１６のデータテーブル１３２ａに含まれる他の情報については説明を省略する。

そして、図１７に示すデータテーブル１３２ｂは、図１６で説明したデータテーブル１３２ａと同じ項目を有している。具体的に、図１７に示すデータテーブル１３２ｂにおいて、「項番」が「１３」である情報には、「登録日」として「２０１４／９／１」が設定され、「氏名」として「ＮＮＮ」が設定され、「所在地」として「神奈川」が設定され、「年齢」として「２５」が設定されている。図１７のデータテーブル１３２ｂに含まれる他の情報については説明を省略する。

すなわち、図１６及び図１７に示す例において、データテーブル１３２に含まれる情報のうち、「登録日」が２０１４年８月である情報は、データテーブル１３２ａに含まれている。また、データテーブル１３２に含まれる情報のうち、「登録日」が２０１４年９月である情報は、データテーブル１３２ｂに含まれている。そのため、例えば、データテーブル１３２に含まれる情報のうち、２０１４年８月に登録された情報のみが不要になった場合、事業者は、データテーブル１３２ａのみの削除を行うことで、不要な情報の削除を行うことが可能になる。これにより、事業者は、情報の削除等を含めた情報の管理を容易に行うことが可能になる。

[インデックスの具体例]
次に、インデックス１３４の具体例について説明を行う。図１８及び図１９は、インデックス１３４の具体例を説明する図である。具体的に、図１８は、図１６で説明したデータテーブル１３２ａに対するアクセス時間を短縮するためのインデックス１３４ａであり、図１９は、図１７で説明したデータテーブル１３２ｂに対するアクセス時間を短縮するためのインデックス１３４ｂである。

図１８に示すインデックス１３４ａには、インデックス１３４ａに含まれる各情報を識別する「項番」と、図１６で説明した「所在地」と、図１６で説明したデータテーブル１３２ａの「項番」に対応する「データテーブルの項番」とを項目として有している。

具体的に、図１８に示すインデックス１３４ａにおいて、「項番」が「１」である情報には、「所在地」として「東京」が設定され、「データテーブルの項番」として「１，８，１０，１１」が設定されている。すなわち、図１８に示すインデックス１３４ａの「データテーブルの項番」には、図１６に示すデータテーブル１３２ａに含まれる情報にうち、「所在地」に「東京」が設定された情報の「項番」である「１，８，１０，１１」が設定されている。

これにより、情報処理装置１のアクセス実行部１１３は、データテーブル１３２ａから「所在地」が「東京」である情報を抽出する場合に、図１８に示すインデックス１３４を参照することで、抽出すべき情報の「項番」を特定することが可能になる。そのため、アクセス実行部１１３は、データテーブル１３２ａに含まれる全ての情報を走査することなく、必要な情報に迅速にアクセスすることが可能になる。図１８のインデックス１３４ａに含まれる他の情報については説明を省略する。

そして、図１９に示すインデックス１３４ｂは、図１８で説明したインデックス１３４ａと同じ項目を有している。具体的に、図１９に示すインデックス１３４ｂにおいて、「項番」が「１」である情報には、「所在地」として「東京」が設定され、「データテーブルの項番」として「１６，１８，２２」が設定されている。図１９のインデックス１３４ｂに含まれる他の情報については説明を省略する。

[アクセスプランの具体例]
次に、アクセスプラン１３１の具体例について説明を行う。図２０は、アクセスプラン１３１の具体例を説明する図である。

図２０に示すアクセスプラン１３１には、アクセスプラン１３１に含まれる各情報を識別する「項番」と、情報処理装置１が利用者端末２１から受信したアクセス要求の内容（ＳＱＬ文）が設定される「アクセス要求」とを項目として有する。また、図２０に示すアクセスプラン１３１には、「アクセス要求」に設定された内容のアクセス要求を行う際に、インデックス１３４ａ及びインデックス１３４ｂを参照してアクセスを行うか否かについての情報である「インデックス参照要否」を項目として有する。

具体的に、図２０に示すアクセスプラン１３１において、「項番」が「１」である情報には、「アクセス要求」として、利用者表のうち、「所在地」が「大阪」である情報の全ての項目を抽出するためのＳＱＬ文である「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ所在地＝大阪」が設定されている。また、図２０に示すアクセスプラン１３１において、「項番」が「１」である情報には、「インデックス参照要否」として、インデックス１３４ａ及びインデックス１３４ｂを参照することを示す「１３４ａ、１３４ｂ参照」が設定されている。そのため、アクセス実行部１１３は、アクセスプラン１３１の「項番」が「１」である情報に対応する「アクセス要求」に設定された内容のアクセス要求が発生した場合、インデックス１３４ａ及び１３４ｂを参照した上で、データテーブル１３２の参照を行う。

また、図２０に示すアクセスプラン１３１において、「項番」が「２」である情報には、「アクセス要求」として、利用者表のうち、「氏名」が「ＥＥＥ」である情報の全ての項目を抽出するためのＳＱＬ文である「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ氏名＝ＥＥＥ」が設定されている。また、図２０に示すアクセスプラン１３１において、「項番」が「２」である情報には、「インデックス参照要否」として、インデックス１３４ａ及びインデックス１３４ｂを参照しない（データテーブル１３２の全走査を行う）ことを示す「参照しない」が設定されている。そのため、アクセス実行部１１３は、アクセスプラン１３１の「項番」が「２」である情報に対応する「アクセス要求」に設定された内容のアクセス要求が発生した場合、インデックス１３４ａ及びインデックス１３４ｂを参照せずに、直接データテーブル１３２の参照を行う。図２０に示すアクセスプラン１３１に含まれる他の情報については説明を省略する。

[インデックス追加処理］
次に、ＤＢ制御処理と並行して実行されるインデックス１３４の追加を行う処理（以下、インデックス追加処理とも呼ぶ）について説明を行う。図１２は、第１の実施の形態におけるインデックス追加処理を説明するフローチャートである。なお、以下、インデックス１３４ｃ及びインデックス１３４ｄが新たに追加される場合のインデックス追加処理について説明を行う。

情報処理装置１のインデックス管理部１１５は、インデックス追加要求を受信するまで待機する（Ｓ１０１のＮＯ）。そして、インデックス追加要求を受信した場合（Ｓ１０１のＹＥＳ）、インデックス管理部１１５は、追加予定のインデックス１３４の作成を開始する（Ｓ１０２）。具体的に、インデックス管理部１１５は、インデックス１３４を記憶するためのインデックス領域を確保する。そして、インデックス管理部１１５は、インデックス１３４を確保したインデックス領域に記憶する。

その後、インデックス管理部１１５は、追加予定のインデックス１３４のうち、追加が完了したインデックス１３４が発生するまで待機する（Ｓ１０３のＮＯ）。そして、追加が完了したインデックス１３４が発生した場合（Ｓ１０３のＹＥＳ）、情報管理部１１２は、状態情報１３５の更新を行う（Ｓ１０４）。以下、状態情報１３５の具体例について説明を行う。

[状態情報の具体例］
図２１は、状態情報１３５の具体例を説明する図である。図２１に示す状態情報１３５は、状態情報１３５に含まれる各情報を識別する「項番」と、追加予定のインデックス１３４を識別する「識別情報」と、各インデックス１３４の追加が完了したか否かを示す「追加完了フラグ」とを項目として有する。「追加完了フラグ」には、インデックス１３４の追加が完了したことを示す「１」、または、インデックス１３４の追加が完了していないことを示す「０」が設定される。

具体的に、図２１に示す状態情報１３５において、「項番」が「１」である情報には、「識別情報」として、インデックス１３４ｃを示す「１３４ｃ」が設定されており、「追加完了フラグ」には、「１」が設定されている。また、図２１に示す状態情報１３５において、「項番」が「２」である情報には、「識別情報」として、インデックス１３４ｄを示す「１３４ｄ」が設定されており、「追加完了フラグ」には、「０」が設定されている。すなわち、図２１に示す状態情報１３５は、インデックス１３４ｃに対応するインデックス１３４の追加のみが完了していることを示している。

これにより、アクセスプラン作成部１１１は、状態情報１３５を参照し、インデックス１３４の追加が現在行われているか否かを判定することが可能になる。そのため、アクセスプラン作成部１１１は、後述するように、インデックス１３４の追加が現在行われているか否かに応じた処理の実行を行うことが可能になる。

図１２に戻り、Ｓ１０４の処理の後、インデックス管理部１１５は、追加される予定のインデックス１３４の追加が全て完了したか否かを判定する（Ｓ１０５）。そして、全てのインデックス１３４の追加が完了していない場合（Ｓ１０５のＮＯ）、Ｓ１０３以降の処理を再度実行する。一方、全てのインデックス１３４の追加が完了した場合（Ｓ１０５のＹＥＳ）、インデックス管理部１１５は、インデックス追加処理を終了する。

[インデックスの具体例］
次に、図１２で説明したインデックス追加処理によって追加されたインデックス１３４ｃ及び１３４ｄの具体例について説明を行う。図２２及び図２３は、インデックス１３４の具体例を説明する図である。なお、インデックス１３４ｃは、図１６で説明したデータテーブル１３２ａに対応するインデックスであり、インデックス１３４ｄは、図１７で説明したデータテーブル１３２ｂに対応するインデックスである。

図２２に示すインデックス１３４ｃには、インデックス１３４ｃに含まれる各情報を識別する「項番」と、図１６で説明した「年齢」と、図１６で説明したデータテーブル１３２ａの「項番」に対応する「データテーブルの項番」とを項目として有している。

具体的に、図２２に示すインデックス１３４ｃにおいて、「項番」が「１」である情報には、「年齢」として「２０歳代」が設定され、「項番」として「３，５，７」が設定されている。すなわち、図２２に示すインデックス１３４ｃの「データテーブルの項番」には、図１６に示すデータテーブル１３２ａに含まれる情報にうち、「年齢」に「２０」から「２９」のいずれかが設定された情報の「項番」である「３，５，７」が設定されている。

これにより、アクセス実行部１１３は、データテーブル１３２ａから「年齢」が「２０」から「２９」である情報を抽出する必要がある場合に、図２２に示すインデックス１３４ｃを参照することで、抽出すべき情報の「項番」を特定することが可能になる。そのため、アクセス実行部１１３は、この場合、データテーブル１３２ａに含まれる全ての情報を走査する必要がなくなる。図２２のインデックス１３４ｃに含まれる他の情報については説明を省略する。

そして、図２３に示すインデックス１３４ｄは、図２２で説明したインデックス１３４ｃと同じ項目を有している。具体的に、図２３に示すインデックス１３４ｄにおいて、「項番」が「１」である情報には、「年齢」として「２０歳代」が設定され、「データテーブルの項番」として「１３，１４，２０」が設定されている。図２３のインデックス１３４ｄに含まれる他の情報については説明を省略する。

すなわち、事業者は、インデックス１３４ｃ及びインデックス１３４ｄを追加することにより、「所在地」に設定された情報を条件とするインデックス（インデックス１３４ａ、１３４ｂ）に加え、「年齢」に設定された情報を条件とするインデックスを作成することが可能になる。これにより、事業者は、「年齢」に設定された情報を条件として情報の抽出を行うアクセス要求を受信した場合についても、アクセスに要する時間を短縮させることが可能になる。

[アクセス要求を受信した場合のＤＢ制御処理］
次に、情報処理装置１が利用者端末２１からアクセス要求を受信した場合のおけるＤＢ制御処理について説明を行う。図１３から図１５は、第１の実施の形態におけるＤＢ制御処理を説明するフローチャートである。以下、アクセスプラン再作成部１１４がアクセスプラン１３１の削除のみを行う場合ものとして説明を行う。

アクセス実行部１１３は、利用者端末２１からデータベース２に記憶されたデータテーブル１３２に対するアクセス要求を受信するまで待機する（Ｓ１１のＮＯ）。そして、アクセス要求を受信した場合（Ｓ１１のＹＥＳ）、アクセスプラン再作成部１１４は、データベース２の設定が変更されているか否かを判定する（Ｓ１２）。データベース２の設定の変更は、例えば、パーティションの追加や変更である。

具体的に、事業者は、例えば、データベース２の設定の変更を行った場合に、メモリ１０２上の所定の記憶領域に、データベース２の設定の変更を行ったことを示す情報を記憶する。そして、インデックス管理部１１５は、メモリ１０２上にその情報が存在するか否かと判定することにより、データベース２の設定の変更が行われたか否かを判定するものであってよい。

その後、データベース２の設定の変更が行われたと判定した場合（Ｓ１２のＹＥＳ）、アクセスプラン再作成部１１４は、変更されたデータベース２の設定に対応するアクセスプラン１３１を削除する（Ｓ１３）。一方、データベース２の設定の変更が行われていない場合（Ｓ１２のＮＯ）、アクセスプラン再作成部１１４は、Ｓ１３の処理を実行しない。

すなわち、データベース２の設定が変更された場合、アクセスプラン再作成部１１４は、その変更前のデータベース２の設定に基づいて作成されたアクセスプラン１３１を更新する必要がある。そのため、アクセスプラン再作成部１１４は、この場合、設定が変更されたデータベース２に対応するアクセスプラン１３１を削除する。

なお、Ｓ１２の処理におけるデータベース２の設定の変更には、図１２で説明したインデックス１３４の追加が含まれないものとする。そのため、インデックス１３４の追加のみが行われた場合（インデックス１３４の追加のみが行われている場合）、アクセスプラン再作成部１１４は、Ｓ１３の処理を実行しない。

その後、アクセスプラン作成部１１１は、Ｓ１１の処理で受信したアクセス要求に対応するアクセスプラン１３１が存在するか否かを判定する（Ｓ１４）。その結果、Ｓ１１の処理で受信したアクセス要求に対応するアクセスプラン１３１が存在する場合（Ｓ１４のＹＥＳ）、アクセスプラン作成部１１１は、インデックス１３４の追加が現在行われているか否かを判定する（Ｓ１５）。具体的に、アクセスプラン作成部１１１は、この場合、判定情報１３３を参照することにより、インデックス１３４の追加が行われているか否かを判定する。以下、判定情報１３３の具体例について説明を行う。

[判定情報の具体例］
図２４及び図２５は、判定情報１３３の具体例を説明する図である。初めに、インデックスの追加が行われていない場合の判定情報１３３について説明を行う。図２４は、インデックスの追加が行われていない場合の判定情報１３３の具体例を説明する図である。

図２４に示す判定情報１３３は、判定情報１３３に含まれる各情報を識別する「項番」と、インデックス１３４の追加が行われているか否かを示す「判定フラグ」とを項目として有する。「判定フラグ」には、インデックス１３４の追加が現在行われていることを示す「１」、または、インデックス１３４の追加が行われていないことを示す「０」が設定される。

具体的に、図２４に示す例において、「項番」が「１」である情報の「判定フラグ」には、「０」が設定されている。すなわち、図２４に示す判定情報１３３は、インデックス１３４の追加が現在行われていないことを示している。

次に、インデックスの追加が行われている場合の判定情報１３３について説明を行う。図２５は、インデックスの追加が行われている場合の判定情報１３３の具体例を説明する図である。

図２５に示す判定情報１３３は、図２４で説明した判定情報１３３と同じ項目を有している。そして、図２５に示す例において、「項番」が「１」である情報の「判定フラグ」には、「１」が設定されている（図２５の下線部分）。

なお、判定情報１３３は、表毎に「判定フラグ」の項目を有しているものであってもよい。これにより、アクセスプラン作成部１１１は、インデックス１３４の追加が行われているか否かに応じて実行する処理の内容を、表毎に分けて決定することが可能になる。

また、判定情報１３３は、インデックス１３４の種類毎に「判定フラグ」の項目を有しているものであってもよい。具体的に、判定情報１３３は、「所在地」に関するインデックスであるインデックス１３４ａ、１３４ｂと、「年齢」に関するインデックスであるインデックス１３４ｃ、１３４ｄとで、それぞれ「判定フラグ」の項目を有しているものであってよい。これにより、アクセスプラン作成部１１１は、インデックス１３４の追加が行われているか否かに応じて実行する処理の内容を、インデックス１３４の種類毎に分けて決定することが可能になる。

図１３に戻り、Ｓ１５の処理の結果、インデックス１３４の追加が行われていると判定した場合（Ｓ１５のＹＥＳ）、情報管理部１１２は、全てのインデックス１３４の追加が完了しているか否かを判定する（Ｓ１６）。具体的に、情報管理部１１２は、状態情報１３５を参照し、追加予定の全てのインデックス１３４に対応する「追加完了フラグ」に「１」が設定されているか否かを判定する。

そして、全てのインデックス１３４の追加が完了していないと判定した場合（Ｓ１５のＮＯ）、アクセス実行部１１３は、図１４に示すように、Ｓ１１の処理で受信したアクセス要求に対応するアクセスプラン１３１を参照し、データテーブル１３２に対するアクセスを行う（Ｓ２１）。その後、アクセス実行部１１３は、Ｓ２１の処理におけるアクセスの結果を、アクセス要求の送信元（利用者端末２１）に送信する（Ｓ２２）。

すなわち、アクセスプラン作成部１１１及びアクセスプラン再作成部１１４は、インデックス１３４の追加が行われている間（Ｓ１５のＹＥＳ、Ｓ１６のＮＯ）、アクセスプラン１３１の削除や新たな作成を行わずに、情報格納領域１３０に記憶されているアクセスプラン１３１を維持する。そのため、アクセスプラン作成部１１１は、インデックス１３４の追加されている間にアクセス要求を受信した場合、インデックス１３４の追加が行われる前に作成されたアクセスプラン１３１を参照して、データテーブル１３２に対するアクセスを行う。これにより、アクセスプラン作成部１１１は、インデックス１３４の追加が行われている間に、アクセスプラン１３１を参照したアクセスが行われても、アクセスの失敗が発生することを防止することが可能になる。

また、アクセス実行部１１３は、インデックス１３４の追加が行われていない場合についても（Ｓ１５のＮＯ）、アクセスプラン１３１を参照してデータテーブル１３２に対するアクセスを行う（Ｓ２１、Ｓ２２）。すなわち、アクセスプラン作成部１１１及びアクセスプラン再作成部１１４は、インデックス１３４の追加が行われていない場合についても、アクセスプラン１３１の削除や新たな作成を行わない。これにより、アクセスプラン作成部１１１及びアクセスプラン再作成部１１４は、アクセスプラン１３１の削除や新たな作成に伴う処理負担を軽減させることが可能になる。

一方、Ｓ１６の処理において、全てのインデックス１３４の追加が完了していると判定した場合（Ｓ１６のＹＥＳ）、情報管理部１１２は、インデックス１３４の追加が行われていないことを示すように判定情報１３３を更新する（Ｓ１７）。すなわち、情報管理部１１２は、インデックス１３４の追加が完了した旨を判定情報１３３に反映させる。

その後、アクセスプラン再作成部１１４は、追加が完了したインデックス１３４に対応するアクセスプラン１３１を全て削除する（Ｓ１８）。具体的に、アクセスプラン再作成部１１４は、例えば、追加されたインデックス１３４に含まれる情報を参照するアクセスプラン１３１を全て削除する。

すなわち、全てのインデックス１３４の追加が完了した場合、アクセスプラン作成部１１１がインデックス１３４を参照しても、アクセスの失敗は発生しない。そのため、アクセスプラン作成部１１１は、この場合、追加されたインデックス１３４を参照する場合を含むアクセスプラン１３１を再作成する必要がある。したがって、アクセスプラン再作成部１１４は、全てのインデックス１３４の追加が完了していると判定した場合、追加されたインデックス１３４に対応するアクセスプラン１３１を全て削除する。これにより、アクセスプラン作成部１１１は、後述するように、新たなアクセスプラン１３１の作成（アクセスプラン１３１の再作成）を行うことが可能になる。

そして、Ｓ１８の処理の後、または、Ｓ１１の処理で受信したアクセス要求に対応するアクセスプラン１３１が存在しないと判定された場合（Ｓ１４のＮＯ）、アクセスプラン作成部１１１は、図１５に示すように、インデックス１３４の現在追加が行われているか否かを再度判定する（Ｓ３１）。

そして、インデックス１３４の追加が行われていると判定した場合（Ｓ３１のＹＥＳ）、情報管理部１１２は、インデックスの追加が行われていることを示すように判定情報１３３の更新を行う（Ｓ３２）。その後、アクセスプラン作成部１１１は、データテーブル１３２を全走査することによりデータテーブル１３２に対するアクセスを行うように、アクセスプラン１３１を作成する（Ｓ３３）。

すなわち、Ｓ３１の処理が行われる場合、Ｓ１１の処理で受信したアクセス要求に対応するアクセスプラン１３１は存在しない（Ｓ１２のＮＯ、Ｓ１６）。そのため、アクセスプラン作成部１１１は、インデックス１３４の追加が行われていると判定した場合（Ｓ３１のＹＥＳ）、追加予定のインデックス１３４を参照することがないように、アクセスプラン１３１の作成を行う（Ｓ３３）。これにより、アクセスプラン作成部１１１は、アクセスの失敗が発生することを防止することが可能になる。

一方、インデックス１３４の追加が行われていないと判定した場合（Ｓ３１のＮＯ）、アクセスプラン作成部１１１は、データテーブル１３２を全走査することにより、または、インデックス１３４を参照することによりデータテーブル１３２に対するアクセスを行うように、アクセスプラン１３１を作成する（Ｓ３４）。すなわち、アクセスプラン作成部１１１は、インデックス１３４の追加が行われていない場合、インデックス１３４を参照してもアクセスの失敗は発生しない。そのため、アクセスプラン作成部１１１は、この場合、インデックス１３４を参照する場合を含めてアクセスプラン１３１を作成する。

その後、アクセス実行部１１３は、利用者端末２１からデータベース２に記憶されたデータテーブル１３２に対するアクセス要求を再度受信するまで待機する（Ｓ１１のＮＯ）。

[ＤＢ制御処理の具体例］
次に、ＤＢ制御処理の具体例について説明を行う。以下、図２０で説明したアクセスプラン１３１が既に存在している場合におけるＤＢ制御処理の具体例について説明を行う。なお、以下、データベース２の設定の変更は行われていないものとする。

初めに、インデックス１３４の追加が行われている場合（Ｓ１５のＹＥＳ、Ｓ１６のＮＯ）におけるアクセスプラン１３１の具体例について説明を行う。図２６及び図２７は、インデックス１３４の追加が行われている場合におけるアクセスプラン１３１の具体例を説明する図である。

例えば、アクセス要求として「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＞４０」を受信した場合（Ｓ１１のＹＥＳ）、アクセスプラン作成部１１１は、そのアクセス要求に対応するアクセスプラン１３１が情報格納領域１３０に存在するか否かを判定する（Ｓ１４）。

具体的に、図２０に示すアクセスプラン１３１における「項番」が「３」である情報の「アクセス要求」には、受信したアクセス要求である「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＞４０」が設定されている。そのため、アクセスプラン作成部１１１は、受信したアクセス要求に対応するアクセスプラン１３１が存在すると判定する（Ｓ１４のＹＥＳ）。

そして、アクセスプラン作成部１１１は、存在したアクセスプラン１３１を参照して、データテーブル１３２に対するアクセスを行う（Ｓ２１）。また、アクセスプラン作成部１１１は、図２６の下線部分に示すように、図２０のアクセスプラン１３１における「項番」が「３」である情報を維持する。

その後、図２６の状態の後、アクセス要求として「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」を受信した場合、アクセスプラン作成部１１１は、図２６で説明した場合と同様に、そのアクセス要求に対応するアクセスプラン１３１が情報格納領域１３０に存在するか否かを判定する（Ｓ１４）。

具体的に、図２６のアクセスプラン１３１には、「アクセス要求」に「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」が設定されている情報は存在しない（Ｓ１４のＮＯ）。そのため、アクセスプラン作成部１１１は、図２７の下線部分に示すように、「アクセス要求」に「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」が設定され、「インデックス参照要否」に「参照しない」が設定された情報（「項番」が「６」である情報）を情報格納領域１３０に記憶する（Ｓ３１のＹＥＳ、Ｓ３３）。

すなわち、アクセスプラン作成部１１１は、インデックス１３４の追加が行われている間にアクセス要求を受信した場合、追加されるインデックス（インデックス１３４ｃ及びインデックス１３４ｄ）が参照されないように、アクセスプラン１３１の作成（更新）を行う。これにより、アクセスプラン作成部１１１は、インデックス１３４の追加が行われている間に、新たに発生したアクセス要求によって、追加されるインデックス１３４が参照されることを防止することが可能になる。そのため、アクセスプラン作成部１１１は、アクセス実行部１１３によるアクセスの失敗の発生を防止することが可能になる。

次に、インデックス１３４の追加が完了した場合（Ｓ１５のＹＥＳ、Ｓ１６のＹＥＳ）におけるアクセスプラン１３１の具体例について説明を行う。図２８及び図２９は、インデックス１３４の追加が完了した場合におけるアクセスプラン１３１の具体例を説明する図である。

例えば、図２７に示す状態の後、アクセス要求として「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＜＝３０」を受信した場合であって（Ｓ１１のＹＥＳ）、インデックス１３４ｃ及びインデックス１３４ｄの追加が完了している場合（Ｓ１５のＹＥＳ、Ｓ１６のＹＥＳ）、アクセスプラン再作成部１１４は、追加されたインデックス１３４に対応するアクセスプラン１３１を削除する（Ｓ１８）。

具体的に、インデックス１３４ｃ及びインデックス１３４ｄは、「年齢」に設定された情報に関するインデックスである。そして、図２７に示すアクセスプラン１３１において、「年齢」に設定された情報に関する条件を含むアクセス要求は、「項番」が「３」及び「６」である情報である。そのため、アクセスプラン再作成部１１４は、この場合、図２８に示すように、図２７で説明したアクセスプラン１３１のうち、「項番」が「３」及び「６」である情報を削除する。

その後、アクセスプラン作成部１１１は、「アクセス要求」が「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＜＝３０」であるアクセスプラン１３１を情報格納領域１３０に記憶する（Ｓ３１のＮＯ、Ｓ３４）。

具体的に、アクセスプラン作成部１１１は、このアクセス要求が「年齢」に設定された情報を条件として含んでいると判定する。さらに、アクセスプラン作成部１１１は、「年齢」に設定された情報に対するインデックスとしてインデックス１３４ｃ及びインデックス１３４ｄが情報格納領域１３０に記憶されていると判定する。そのため、アクセスプラン作成部１１１は、図２９の下線部分に示すように、「アクセス要求」に「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＜＝３０」が設定され、「インデックス参照要否」に「１３４ｃ、１３４ｄ参照」が設定された情報（「項番」が「７」である情報）を情報格納領域１３０に記憶する（Ｓ３４）。

これにより、アクセスプラン作成部１１１は、アクセス実行部１１３によるデータベース２へのアクセスに要する時間を短縮させることが可能になる。

次に、インデックス１３４の追加が行われていない場合（Ｓ１５のＮＯ）におけるアクセスプラン１３１の具体例について説明を行う。図３０は、インデックス１３４の追加が行われていない場合におけるアクセスプラン１３１の具体例を説明する図である。

例えば、図２９に示す状態の後、アクセス要求として「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」を受信した場合、アクセスプラン作成部１１１は、そのアクセス要求に対応するアクセスプラン１３１が情報格納領域１３０に存在するか否かを判定する（Ｓ１４）。

具体的に、図２９のアクセスプラン１３１において、「アクセス要求」に「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」が設定されている情報は存在しない（Ｓ１４のＮＯ）。また、アクセスプラン作成部１１１は、受信したアクセス要求は、「年齢」に設定された情報を条件として含んでいると判定する。さらに、アクセスプラン作成部１１１は、「年齢」に設定された情報に対するインデックスとしてインデックス１３４ｃ及びインデックス１３４ｄが情報格納領域１３０に記憶されていると判定する。そのため、アクセスプラン作成部１１１は、図３０の下線部分に示すように、「アクセス要求」に「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」が設定され、「インデックス参照要否」に「１３４ｃ、１３４ｄ参照」が設定された情報（「項番」が「８」である情報）を情報格納領域１３０に記憶する（Ｓ３１のＮＯ、Ｓ３４）。

なお、「ＳＥＬＥＣＴ＊ＦＲＯＭ利用者表ＷＨＥＲＥ年齢＝２５」は、情報格納領域１３０に以前記憶されていたアクセスプラン１３１であるが、アクセスプラン作成部１１１は、以前記憶されていたか否かを問わずに、新たなアクセスプラン１３１の作成を行う。すなわち、図２８で説明したように、アクセスプラン再作成部１１４は、追加されたインデックス（インデックス１３４ｃ及びインデックス１３４ｄ）に対応するアクセスプラン１３１の削除を行う。そして、アクセスプラン作成部１１１は、新たなアクセスプラン１３１の作成を行う。

これにより、情報処理装置１は、インデックス１３４の追加が行われている場合であっても、アクセス失敗を発生させることなく、データテーブル１３２に対するアクセスを行うことが可能になる。そのため、情報処理装置１は、データテーブルが参照されている間にインデックスの追加を行うことが可能になる。

以上の実施の形態をまとめると、以下の付記のとおりである。

（付記１）
コンピュータに、
データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成し、
前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成する、
ことを実行させることを特徴とするデータベース制御プログラム。

（付記２）
付記１において、
前記データテーブルは、複数の記憶領域に分割されて記憶されており、
追加される前記インデックスは、前記複数の記憶領域に含まれる１以上の記憶領域それぞれに対応する１以上のインデックスであり、
前記アクセスプランを再作成する処理では、前記１以上のインデックスの全ての追加が完了した場合に、前記アクセスプランの再作成を行う、
ことを特徴とするデータベース制御プログラム。

（付記３）
付記１において、
前記アクセスプランを作成する処理では、前記インデックスの追加が発生した後であって前記インデックスの追加が完了するまでの間において、前記データテーブルに対するアクセスを行うためのアクセス要求を受け付けた際に、前記アクセス要求に対応する前記アクセスプランの作成を行い、
前記アクセスプランを再作成する処理では、前記インデックスの追加が完了した後、前記アクセス要求を再度受け付けた際に、前記アクセス要求に対応する前記アクセスプランの再作成を行う、
ことを特徴とするデータベース制御プログラム。

（付記４）
付記１において、
前記アクセスプランを再作成する処理では、作成された前記アクセスプランを削除し、
前記アクセスプランを作成する処理では、受け付けた前記アクセス要求に対応するアクセスプランが存在しない場合に、削除された前記アクセスプランを含めて、受け付けた前記アクセス要求に対応する前記アクセスプランの作成を行う、
ことを特徴とするデータベース制御プログラム。

（付記５）
付記１において、
前記アクセスプランを作成する処理では、前記インデックスの追加が行われていない間に作成された前記アクセスプランが存在する場合、前記アクセスプランの作成を行わず、存在した前記アクセスプランを維持する、
ことを特徴とするデータベース制御プログラム。

（付記６）
付記１において、
前記アクセスプランを作成する処理では、前記インデックスを参照せずに前記データテーブルに対するアクセスが行われるように、前記アクセスプランを作成する、
ことを特徴とするデータベース制御プログラム。

（付記７）
データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成するアクセスプラン作成部と、
前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成するアクセスプラン再作成部と、を有する、
ことを特徴とするデータベース制御装置。

（付記８）
付記７において、
前記アクセスプラン作成部は、前記インデックスの追加が発生した後であって前記インデックスの追加が完了するまでの間において、前記データテーブルに対するアクセスを行うためのアクセス要求を受け付けた際に、前記アクセス要求に対応する前記アクセスプランの作成を行い、
前記アクセスプラン再作成部は、前記インデックスの追加が完了した後、前記アクセス要求を再度受け付けた際に、前記アクセス要求に対応する前記アクセスプランの再作成を行う、
ことを特徴とするデータベース制御装置。

（付記９）
データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成し、
前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成する、
ことを特徴とするデータベース制御方法。

（付記１０）
付記９において、
前記アクセスプランを作成する工程では、前記インデックスの追加が発生した後であって前記インデックスの追加が完了するまでの間において、前記データテーブルに対するアクセスを行うためのアクセス要求を受け付けた際に、前記アクセス要求に対応する前記アクセスプランの作成を行い、
前記アクセスプランを再作成する工程では、前記インデックスの追加が完了した後、前記アクセス要求を再度受け付けた際に、前記アクセス要求に対応する前記アクセスプランの再作成を行う、
ことを特徴とするデータベース制御方法。

１：情報処理装置２：データベース
２１：利用者端末１３０：記憶部
１３１：アクセスプラン

Claims

コンピュータに、
データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成し、
前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成する、
ことを実行させることを特徴とするデータベース制御プログラム。
請求項１において、
前記データテーブルは、複数の記憶領域に分割されて記憶されており、
追加される前記インデックスは、前記複数の記憶領域に含まれる１以上の記憶領域それぞれに対応する１以上のインデックスであり、
前記アクセスプランを再作成する処理では、前記１以上のインデックスの全ての追加が完了した場合に、前記アクセスプランの再作成を行う、
ことを特徴とするデータベース制御プログラム。
請求項１において、
前記アクセスプランを作成する処理では、前記インデックスの追加が発生した後であって前記インデックスの追加が完了するまでの間において、前記データテーブルに対するアクセスを行うためのアクセス要求を受け付けた際に、前記アクセス要求に対応する前記アクセスプランの作成を行い、
前記アクセスプランを再作成する処理では、前記インデックスの追加が完了した後、前記アクセス要求を再度受け付けた際に、前記アクセス要求に対応する前記アクセスプランの再作成を行う、
ことを特徴とするデータベース制御プログラム。
請求項１において、
前記アクセスプランを再作成する処理では、作成された前記アクセスプランを削除し、
前記アクセスプランを作成する処理では、受け付けた前記アクセス要求に対応するアクセスプランが存在しない場合に、削除された前記アクセスプランを含めて、受け付けた前記アクセス要求に対応する前記アクセスプランの作成を行う、
ことを特徴とするデータベース制御プログラム。
請求項１において、
前記アクセスプランを作成する処理では、前記インデックスの追加が行われていない間に作成された前記アクセスプランが存在する場合、前記アクセスプランの作成を行わず、存在した前記アクセスプランを維持する、
ことを特徴とするデータベース制御プログラム。
請求項１において、
前記アクセスプランを作成する処理では、前記インデックスを参照せずに前記データテーブルに対するアクセスが行われるように、前記アクセスプランを作成する、
ことを特徴とするデータベース制御プログラム。
データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成するアクセスプラン作成部と、
前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成するアクセスプラン再作成部と、を有する、
ことを特徴とするデータベース制御装置。
データベースに記憶されたデータテーブルについてのインデックスの追加が発生したときに、前記インデックスの追加が完了するまでの間、前記データテーブルを全走査することにより前記データテーブルに対するアクセスが行われるように、アクセスプランを作成し、
前記インデックスの追加が完了した後、追加された前記インデックスを参照して前記データテーブルに対するアクセスが行われるように、前記アクセスプランを再作成する、
ことを特徴とするデータベース制御方法。