(57)【要約】【課題】あるユーザアプリケーションについて、問い合わせ結果を求める際の性能が良いアクセスパスを生成するためのインデクスを追加、変更又は削除する際に、他のユーザアプリケーションに対応するアクセスパスに影響を与えないことを実現する。【解決手段】データベース管理装置のプロセッサが、複数のインデクスをグループ化することによりインデクスグループを作成し、インデクスグループの指定されたアクセス要求を受け付け、インデクスグループに含まれるインデクスの中から問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択し、当該インデクスを利用してアクセスパスを生成する。【選択図】図１
2011107814.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの表を有するデータベースに対するユーザアプリケーションからのアクセス要求に応じて、データベース管理装置のプロセッサが、前記表に設定された複数のインデクスの中からインデクスを選択して生成されたアクセスパスに従って前記表のデータを操作するデータベース管理方法において、
前記プロセッサが、前記複数のインデクスをグループ化することによりインデクスグループを作成するインデクスグループ作成ステップと、
前記プロセッサが、前記インデクスグループの指定されたアクセス要求を受け付け、前記インデクスグループに含まれるインデクスの中から所定のインデクスを選択し、前記所定のインデクスを利用してアクセスパスを生成するアクセスパス作成ステップと
を含むことを特徴とするデータベース管理方法。
【請求項２】
前記インデクスグループ作成ステップは、
前記プロセッサが、前記複数のインデクスと前記インデクスグループとを対応付け、その対応関係を保持する手順を含む
ことを特徴とする請求項１に記載のデータベース管理方法。
【請求項３】
前記プロセッサが、前記アクセスパス作成ステップにおいて生成されたアクセスパスを実行することで、前記アクセス要求に応じて前記表のデータを操作するアクセスパス実行ステップ
を含むことを特徴とする請求項１に記載のデータベース管理方法。
【請求項４】
前記プロセッサが、前記インデクスグループに所属するインデクスを利用して生成されたアクセスパスとともに前記インデクスグループを含めて表示装置に表示するアクセスパス表示ステップ
を含むことを特徴とする請求項１に記載のデータベース管理方法。
【請求項５】
前記プロセッサが、前記インデクスグループに所属するインデクスを変更するインデクス変更ステップを更に含み、
前記インデクス変更ステップでは、
前記プロセッサが、前記インデクスが単一のインデクスグループに所属している場合には前記インデクス自体を直接変更する一方、前記インデクスが複数のインデクスグループに所属している場合には、前記インデクスを複製して同一名称を用いた新規な別のインデクスを作成する別のインデクス作成ステップと、
前記プロセッサが、前記複数のインデクスグループのうち前記別のインデクスが所属すべきインデクスグループと前記別のインデクスとの対応関係を変更する対応関係変更ステップと
を含むことを特徴とする請求項１に記載のデータベース管理方法。
【請求項６】
前記プロセッサが、前記インデクスグループに所属するインデクスを削除するインデクス削除ステップを更に含み、
前記インデクス削除ステップは、
前記プロセッサが、削除対象の前記インデクスが単一のインデクスグループに所属している場合には前記インデクスを直接削除し、削除対象の前記インデクスが複数のインデクスグループに所属している場合には、前記インデクス自体を削除する代わりに、前記インデクスグループと前記インデクスの対応関係を削除するステップ
を含むことを特徴とする請求項１に記載のデータベース管理方法。
【請求項７】
前記インデクスグループ作成ステップでは、
前記プロセッサが、前記インデクスグループを定義するためのインデクスグループ定義要求を受け付けて前記インデクスグループを作成する一方、前記インデクスグループに対して前記インデクスを定義するためのインデクス定義要求を受け付けて前記インデクスグループに前記インデクスを定義する
ことを特徴とする請求項１に記載のデータベース管理方法。
【請求項８】
前記プロセッサが、前記インデクスグループと前記ユーザアプリケーションとの対応関係を定義する対応関係定義ステップ
を含むことを特徴とする請求項１に記載のデータベース管理方法。
【請求項９】
前記プロセッサが、前記インデクスグループを複製するとともに、前記インデクスグループに所属している前記インデクスとの対応関係も複製するインデクスグループ複製ステップを含む
ことを特徴とする請求項１に記載のデータベース管理方法。
【請求項１０】
少なくとも１つの表を有するデータベースに対するユーザアプリケーションからのアクセス要求に応じて、前記表に設定された複数のインデクスの中からインデクスを選択して生成されたアクセスパスに従って前記表のデータを操作するデータベース管理装置において、
前記複数のインデクスをグループ化することによりインデクスグループを作成するインデクスグループ管理部と、
前記インデクスグループの指定されたアクセス要求を受け付け、前記インデクスグループに含まれるインデクスの中から所定のインデクスを選択し、前記所定のインデクスを利用してアクセスパスを生成するアクセスパス作成部と
を備えることを特徴とするデータベース管理装置。
【請求項１１】
前記アクセスパス作成部によって生成されたアクセスパスを実行することで、前記アクセス要求に応じて前記表のデータを操作するアクセスパス実行部を備える
ことを特徴とする請求項１０に記載のデータベース管理装置。
【請求項１２】
前記インデクスグループ管理部は、
前記複数のインデクスをグループ化することによりインデクスグループを定義する一方、前記インデクスグループに所属させるべきインデクスを定義し、
前記アクセスパス作成部は、
前記アクセス要求を受け付けるアクセス要求受付部と、
前記アクセス要求受付部によって受け付けられたアクセス要求に基づいて、前記インデクスグループに含まれるインデクスの中から所定のインデクスを選択するインデクス選択部と、
前記インデクス選択部によって選択された前記所定のインデクスを利用してアクセスパスを生成するアクセスパス生成部と
を備えることを特徴とする請求項１０に記載のデータベース管理装置。
【請求項１３】
少なくとも１つの表を有するデータベースに対するユーザアプリケーションからのアクセス要求に応じて、データベース管理装置のプロセッサに、前記表に設定された複数のインデクスの中からインデクスを選択して生成されたアクセスパスに従って前記表のデータを操作させるデータベース管理プログラムにおいて、
前記プロセッサに、前記複数のインデクスをグループ化することによりインデクスグループを作成させるインデクスグループ作成ステップと、
前記プロセッサに、前記インデクスグループの指定されたアクセス要求を受け付け、前記インデクスグループに含まれるインデクスの中から所定のインデクスを選択し、前記所定のインデクスを利用してアクセスパスを生成させるアクセスパス作成ステップと
を実行させることを特徴とするデータベース管理プログラム。
【請求項１４】
前記プロセッサに、前記アクセスパス作成ステップにおいて生成されたアクセスパスを実行させることで、前記アクセス要求に応じて前記表のデータを操作させるアクセスパス実行ステップ
を実行させることを特徴とするデータベース管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インデクスを利用して検索を行うデータベースを有するデータベース管理装置に関し、特に、複数のユーザアプリケーションからのアクセス要求に応じてインデクスを選択するための技術に関するデータベース管理方法、データベース管理装置及びデータベース管理プログラムに好適なものである。
【背景技術】
【０００２】
情報化社会の発展に伴い、情報システムの扱うデータの量は日々増加しており、多くの企業が情報システムにデータベース管理システム（DBMS: Database Management System）を利用している。ＤＢＭＳとは、データベースのデータに対する問い合わせに応答するシステムである。
【０００３】
情報システムでは複数のユーザアプリケーションプログラム（User Application Program）が動作している。以下、このようなユーザアプリケーションプログラムを「ＵＡＰ」「ユーザアプリケーション」とも省略する。ユーザアプリケーションは「ＡＰ」などとも呼ばれる。ユーザアプリケーションは、ＤＢＭＳに問い合わせを行うことでデータベースからデータを取得し、取得したデータを利用してサービスを提供する。
【０００４】
ＤＢＭＳでは、データに対する問い合わせを記述する問い合わせ言語として、ＳＱＬがよく利用される。ユーザアプリケーションは、ＤＢＭＳに対してＳＱＬを発行することで問い合わせを行う。ユーザアプリケーションが発行するＳＱＬとしては、ユーザアプリケーション中に直接記述された静的なＳＱＬが存在するとともに、ユーザアプリケーションが生成する動的なＳＱＬが存在する。
【０００５】
ＳＱＬは宣言型の問い合わせ言語であり、その問い合わせには、目的のデータ及びデータの条件を指定する。問い合わせの結果を求めるためにＤＢＭＳがデータベースにアクセスする手順は、ＤＢＭＳ自身が生成する。以下、このようなＤＢＭＳのアクセス手順のことを「アクセスパス」と呼ぶこととする。アクセスパスは、クエリプラン、アクセスプラン又はクエリ実行計画など、様々な名称でも呼ばれる。
【０００６】
近年、ユーザアプリケーションの開発において、ＤＢＭＳの問い合わせ性能のチューニングに多くの時間とコストが掛かる傾向がある。企業間における競争が激化し、さらに、情報システムに対する企業のコスト意識が高まっている中で、ユーザアプリケーションの開発期間の短縮及び開発コストの削減が求められている。そのため、ユーザアプリケーションの開発における、ＤＢＭＳへの問い合わせ性能のチューニングに掛かる時間とコストを短縮する必要が生じている。
【０００７】
ＤＢＭＳへの問い合わせ性能のチューニングが必要となる原因の一つとして、ＤＢＭＳが生成するアクセスパスが、必ずしも問い合わせ結果を求める際の性能が良いアクセスパスであるとは限らないことが挙げられる。そのため、ユーザアプリケーション開発者はアクセスパスを検証して、アクセスパスのチューニングを行う必要がある。
【０００８】
ＤＢＭＳがアクセスパスを生成する際においてはインデクスの存在が影響を与える。インデクスとは、データベースの特定のデータに高速にアクセスするための手段である。問い合わせ結果を求めるためにアクセスが必要となるデータに対するインデクスが存在している場合に、そのインデクスを利用して問い合わせ結果を求めると、そのインデクスを利用しない場合と比較して、問い合わせ結果を求める際の性能が向上するため、ＤＢＭＳは、インデクスを利用したアクセスパスを生成する。そのため、ユーザアプリケーション開発者は、インデクスを作成することでアクセスパスの決定に介入して、より問い合わせ結果を求める際の性能が良いアクセスパスとなるようにチューニングを行うことができる。
【０００９】
具体的な例を示すと、ＤＢＭＳのデータに対するインデクスとは、例えば書籍における索引に相当する。索引のない書籍の場合、その本文の中から目的の情報を探すためには、全てのページを読まなければならず効率が悪い。しかしながら、各章の見出しに対応する索引が存在すると、その本文の中から目的の情報を探すために読まなければならないページ数を限定することができ、索引のない書籍よりも効率的に目的の情報を探すことができる。さらに、本文に含まれるキーワードに対する索引が存在すると、その索引からキーワードを探すことによって、直接目的のページを発見することができ、さらに効率的に目的の情報を探すことができる。このように書籍における索引と同様に、ＤＢＭＳにおいても、インデクスを利用してデータベースにアクセスすることで、効率的に問い合わせ結果を求めることができる。
【００１０】
インデクスは、データベース中に複数存在している。特定のデータ及びデータの組み合わせに対してインデクスを作成することができるため、１つのデータに対して、複数のインデクスが存在している場合がある。ＤＢＭＳがアクセスパスを生成する際には、データベース中に存在する全てのインデクスの中から、問い合わせ結果を求める際の性能が最も良いと判断したインデクスが選択される（非特許文献１参照）。
【００１１】
アクセスパスを生成する際に、データベース中に存在する全てのインデクスから、問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択することで、論理的には、インデクスの追加、変更又は削除が行われた場合にも、常に、問い合わせ結果を求める際の性能が最も良いと考えられるインデクスを選択してアクセスパスを生成することができる仕組みになっている。
【先行技術文献】
【特許文献】
【００１２】
【非特許文献１】"Database Systems : The Complete Book", 2002, Page 757 to 764, Hector Garcia-Molina, Jeffrey D.Ullman and Jennifer Widom, Prentice-Hall、Inc.
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、従来のＤＢＭＳでは、問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択する場合、実際にインデクスを利用して問い合わせ結果を求め、各インデクスを実際に利用した場合の性能を比較している訳ではない。実際のところ、従来のＤＢＭＳは、入力されたＳＱＬを解析し、その解析結果により把握されるＳＱＬと既に存在するインデクスとを比較して、その時点、即ち、各インデクスを実際利用する時点において問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択する。このため、従来のＤＢＭＳにおいては、問い合わせの内容やデータの特徴によっては、問い合わせ結果を求める際の性能が最も良いとは云えないインデクスが選択される場合がある。
【００１４】
この理由について、前述した書籍の索引の例を挙げて説明する。ある書籍に対して、本文中のキーワードに対する索引と、本文中の人物名に対する索引の２つの索引が存在する場合を考える。例えば目的の情報が「ベートーベン」に関する情報であった場合、キーワードに対する索引と、人物名に対する索引のどちらを利用しても探すことはできる。しかしながら、キーワードに対する索引よりも人物名に対する索引の方が索引の項目数が少ない場合、問い合わせの内容である「ベートーベン」は人物名であるため、人物名に対する索引を利用した方がより効率的に目的の情報を探すことができる。このように、問い合わせが人物名であることが分かり、人物名に絞った索引があるということが分かれば、目的の情報である「ベートーベン」を探すための性能が最も良い索引を選択することが可能となる。
【００１５】
この点、ＤＢＭＳは、ＳＱＬによって指定される目的のデータ及びデータの条件が人物名であるのか否かという判別を行うことはできない。そのため、キーワードに対する索引と、人物名に対する索引とが存在した場合に、どちらの索引が選択されるかは、ＤＢＭＳ自身のインデクス選択アルゴリズムに依存する。
【００１６】
このようにデータベースにおけるインデクスは、あるユーザアプリケーションの開発者によってユーザアプリケーションの性能を向上させるために作成されるが、特定のユーザアプリケーションに対して性能が向上するインデクスであっても、他のユーザアプリケーションに対しても性能が向上するとは限らない。すなわち、ユーザアプリケーションごとに、性能の観点で最も良いインデクスがある。
【００１７】
例えば、１つのＤＢＭＳを利用して、最初に第１のユーザアプリケーションの開発を行い、その後、第２のユーザアプリケーションの開発を行う場合を考える。まず、第１のユーザアプリケーションを開発する際、アクセスパスのチューニングを行い、性能要求を満たすために第１のユーザアプリケーションの開発者が問い合わせ結果を求める際の性能が最も良いと判断したアクセスパスで動作するように第１のインデクスを作成する。この時点では、ＤＢＭＳには、第１のインデクスのみが存在するため、第１のユーザアプリケーションのアクセスパス生成時には、必ず、この第１のインデクスが選択される。従って、第１のユーザアプリケーションの開発者は、第１のユーザアプリケーションが実際に第１のユーザアプリケーションの開発者が問い合わせ結果を求める際の性能が最も良いと判断したアクセスパスで動作していることを確認することができる。
【００１８】
その後、第２のユーザアプリケーションを開発する際に、既存の第１のインデクスを利用して生成されたアクセスパスでは、性能上の要件を満たすことができないため、第２のインデクスを新たに作成して追加することでアクセスパスのチューニングを行う。すると、このＤＢＭＳにはインデクスが２つ存在することになる。従来のＤＢＭＳにおいては、アクセスパスを生成する際、その時点に存在する全てのインデクスから選択を行うため、第１又は第２のインデクスが選択されることになる。ここで、第１のユーザアプリケーションのアクセスパス生成時に、開発者の意図しない第２のインデクスが選択され、第１のインデクスが選択されていた時と比べて性能が低下してしまう場合がある。
【００１９】
すなわち、インデクスは全てのアプリケーションにとって問い合わせ結果を求める際の性能が最も良くなるわけではない。第１のユーザアプリケーションには第1のインデクス、第２のユーザアプリケーションには第２のインデクスというように、それぞれのユーザアプリケーションごとに問い合わせ結果を求める際の性能が最も良いインデクスが必要となる。
【００２０】
しかしながら、従来のＤＢＭＳでは、特定のユーザアプリケーションのアクセスパスをチューニングするためにインデクスの追加を行うと、他のユーザアプリケーションのアクセスパスに影響を与えてしまう。これはインデクスを変更又は削除した場合も同様である。そのため、開発者は、インデクスの追加、変更又は削除を行う際に、全てのユーザアプリケーションに対応するアクセスパスの確認を行い、アクセスパスが変化する場合には再度性能の評価を行うことで問題がないことを確認するか、問題がある場合にはチューニングを行う必要が生ずる。ところが、上述した情報システムが大規模となると、膨大な数のユーザアプリケーションが動作しているため、全てのユーザアプリケーションに対応するアクセスパスの確認を行い、上記同様に性能の再評価やチューニングを行うことが、開発期間の長期化を招くとともに開発コストの増加の原因となっている。
【００２１】
本発明は、以上の点を考慮してなされたもので、他のユーザアプリケーションに対応するアクセスパスに影響を与えることなく、ユーザアプリケーションごとに問い合わせ結果を求める際の性能が最も良いアクセスパスを生成するためのインデクスを自由に追加、変更又は削除することができるデータベース管理方法、データベース管理装置及びデータベース管理プログラムを提案するものである。
【課題を解決するための手段】
【００２２】
かかる課題を解決するため、本発明においては、少なくとも１つの表を有するデータベースに対するユーザアプリケーションからのアクセス要求に応じて、データベース管理装置のプロセッサが、前記表に設定された複数のインデクスの中からインデクスを選択して生成されたアクセスパスに従って前記表のデータを操作するデータベース管理方法であって、前記プロセッサが、前記複数のインデクスをグループ化することによりインデクスグループを作成するインデクスグループ作成ステップと、前記プロセッサが、前記インデクスグループの指定されたアクセス要求を受け付け、前記インデクスグループに含まれるインデクスの中からインデクスを選択し、前記選択したインデクスを利用してアクセスパスを生成するアクセスパス作成ステップと、を含むことを特徴とする。
【００２３】
また、本発明においては、少なくとも１つの表を有するデータベースに対するユーザアプリケーションからのアクセス要求に応じて、前記表に設定された複数のインデクスの中からインデクスを選択して生成されたアクセスパスに従って前記表のデータを操作するデータベース管理装置であって、前記複数のインデクスをグループ化することによりインデクスグループを作成するインデクスグループ管理部と、前記インデクスグループの指定されたアクセス要求を受け付け、前記インデクスグループに含まれるインデクスの中からインデクスを選択し、前記選択したインデクスを利用してアクセスパスを生成するアクセスパス作成部と、を有することを特徴とする。
【００２４】
また、本発明においては、少なくとも１つの表を有するデータベースに対するユーザアプリケーションからのアクセス要求に応じて、データベース管理装置のプロセッサに、前記表に設定された複数のインデクスの中からインデクスを選択して生成されたアクセスパスに従って前記表のデータを操作させるデータベース管理プログラムであって、前記プロセッサに、前記複数のインデクスをグループ化することによりインデクスグループを作成させるインデクスグループ作成ステップと、前記プロセッサに、前記インデクスグループの指定されたアクセス要求を受け付け、前記インデクスグループに含まれるインデクスの中からインデクスを選択し、前記選択したインデクスを利用してアクセスパスを生成させるアクセスパス作成ステップと、を実行させることを特徴とする。
【発明の効果】
【００２５】
本発明によれば、他のユーザアプリケーションに対応するアクセスパスに影響を与えることなく、ユーザアプリケーショごとに問い合わせ結果を求める際の性能が最も良いアクセスパスを生成するためのインデクスを自由に追加、変更又は削除することができる。
【図面の簡単な説明】
【００２６】
【図１】本実施の形態によるデータベース管理装置の概略構成を示す概念図である。
【図２】インデクスグループを示す概念図である。
【図３】データベース管理装置の構成の一例を示す機能ブロック図である。
【図４】インデクスグループ管理表を構成する列情報の一例を示す図である。
【図５】インデクスグループを作成するためのインデクスグループ定義要求（ＳＱＬ）の一例を示す図である。
【図６】インデクス管理表を構成する列情報の一例を示す図である。
【図７】インデクス−インデクスグループ対応表を構成する列情報の一例を示す図である。
【図８】インデクスを作成するためのインデクス定義要求（ＳＱＬ）の一例を示す図である。
【図９】インデクスグループを利用する際における手順を示すフローチャートである。
【図１０】インデクスグループを定義する際における処理の手順を示すフローチャートである。
【図１１】インデクスを新たに定義する際における処理の手順を示すフローチャートである。
【図１２】アクセスパスを生成する場合における処理の手順を示すフローチャートである。
【図１３】アクセスパスが出力された際における出力内容の一例を示す図である。
【図１４】インデクス定義を変更する場合における処理の手順を示すフローチャートである。
【図１５】インデクス定義を削除する場合における処理の手順を示すフローチャートである。
【図１６】ユーザアプリケーションとインデクスグループとの対応付けを変更する場合の手順を示すフローチャートである。
【図１７】インデクスグループの複製を作成する場合における処理の手順を示すフローチャートである。
【図１８】インデクスグループを複製するためのインデクスグループ複製要求（ＳＱＬ）の一例を示す図である。
【符号の説明】
【００２７】
１０００……第１のユーザアプリケーション、１１００……第２のユーザアプリケーション、１２００……データベース管理装置、１３００……第１のインデクスグループ、１４００……第２のインデクスグループ、１８００……第１のインデクス、１９００……第２のインデクス、３０００……ユーザアプリケーション、３４００……データベース管理装置、３４１０……プロセッサ、３４２１……アクセスパス、３４３１……定義要求部、３４３２……ＤＢアクセス要求受付部、３４３３……ディスクショナリ管理部、３４３４……アクセスパス生成部、３４３５……アクセスパス実行部、３４３６……アクセスパス表示部、３５３０……インデクスグループ管理表、３５２０……インデクス管理表、３５４０……インデクス−インデクスグループ対応表、３５５０……表、３５６０……インデクス。
【発明を実施するための形態】
【００２８】
以下、図面について、本発明の一実施の形態について詳述する。
【００２９】
（１）本実施の形態によるデータベース管理装置の概略構成
図１は、本実施の形態によるデータベース管理装置１２００の概略構成を示す。データベース管理装置１２００は、例えばワークステーション又はメインフレームのようなコンピュータである。本実施の形態では、データベース管理装置１２００をＤＢＭＳ（Database Management System）とも図示している。
【００３０】
データベース管理装置１２００は、ハードウェア資源として、図示しないプロセッサ、メモリ、キャッシュ、ハードディスクドライブ及びインターフェースを備えている。データベース管理装置１２００においては、プロセッサが、ハードディスクドライブから読み出したデータベース管理プログラムをメモリ上で実行することで、後述する機能を実現する。データベースにおいては、各データを列及び行によって管理する表が作成されており、各表の列には後述するインデクスを設定することができる。インデクスは、データベースにおける各テーブルに対してデータの検索などを行う際に、検索処理などを行い易いようにユーザによって設定される書籍の索引に相当する機能である。
【００３１】
本実施の形態においては、「インデクスグループ」なる新たな概念を定義し、少なくとも１つのインデクスをインデクスグループに所属させてグループ化している。具体的には、インデクスの実体そのものをグループ化するのではなく、アクセスパス生成時に利用するインデクス定義情報１５００をグループ化している。インデクス定義情報１５００は、作成されたインデクスの定義内容を示す情報である。ユーザアプリケーションから問い合わせ（アクセス要求）が行われた際に、データベース管理プログラムは、インデクスグループの指定された問い合わせを受け付け、そのインデクスグループに所属するインデクスの中から、問い合わせ結果を求めるために、最も性能が良いと判断したインデクスを選択してアクセスパスを生成する。
【００３２】
データベース管理装置１２００では、このようなインデクスグループとして、第１のインデクスグループ１３００（以下「ＩＤＸＧＲＰ＿Ａ」とも表現する）及び第２のインデクスグループ１４００（以下「ＩＤＸＧＲＰ＿Ｂ」とも表現する）が定義されている。図示の例は、第１のインデクスグループ１３００に対応付けられた第１のユーザアプリケーション１０００（省略して「ＵＡＰ１」と図示する）が実行された場合におけるデータベース管理装置１２００が実行する処理のイメージを示している。また、図示の例では、第２のインデクスグループ１４００に対応付けられた第２のユーザアプリケーション１１００（省略して「ＵＡＰ２」と図示する）が実行された場合におけるデータベース管理装置１２００が実行する処理のイメージを示している。
【００３３】
第１のインデクスグループ１３００には、第１のユーザアプリケーション１０００を実行する際に、問い合わせ結果を求める際の性能が最も良いアクセスパスを生成するためのインデクスが所属している。第１のインデクスグループ１３００には、所属するインデクスの１つとして、第１のインデクス１８００が存在している。
【００３４】
第２のインデクスグループ１４００には、第２のユーザアプリケーション１１００を実行する際に、問い合わせ結果を求める際の性能が最も良いアクセスパスを生成するためのインデクスが所属している。第２のインデクスグループ１４００には、所属するインデクスの１つとして、第２のインデクス１９００が存在している。
【００３５】
まず、第１のユーザアプリケーション１０００を実行した場合について説明する。データベース管理プログラムは、アクセスパスを生成する際に、上述したインデクス定義情報１５００において第１のインデクスグループ１３００に含まれるインデクスの中から、問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択する。第１のインデクスグループ１３００には、第１のユーザアプリケーション１０００を開発した時にチューニングを行った際に定義したインデクスのみが存在しており、第１のユーザアプリケーション１０００の開発者の意図したとおり、第１のインデクス１８００（図示のＩＤＸ＿Ａに相当）が選択される。
【００３６】
データベース管理プログラムは、第１のインデクス１８００を利用する第１のユーザアプリケーション１０００のためのアクセスパス１６００を生成する。その後、データベース管理プログラムは、このアクセスパス１６００を実行して、実際にデータベースにアクセスする。第１のユーザアプリケーション１０００のアクセスパス１６００には２つの操作が示されており、これら２つの操作として第１及び第２の操作が順番に実行される。
【００３７】
第１の操作では、データベース管理プログラムが、アクセスパスを生成した際に選択した第１のインデクス１８００にアクセスを行う。具体的には、データベース管理プログラムは、第１の操作として、第１のインデクス１８００（ＩＤＸ＿Ａ）をアクセスし、名前と所属コードの条件に合うデータを取得する。一方、第２の操作では、データベース管理プログラムが、社員表２０００にアクセスすることで、第１の操作で取得したデータに対応する社員コードを取得し、第１のユーザアプリケーション１０００の問い合わせに対する実行結果２１００を求める。
【００３８】
次に、第２のユーザアプリケーション１１００を実行した場合について説明する。この場合、データベース管理プログラムは、アクセスパスを生成する際に、インデクス定義情報１５００のうち第２のインデクスグループ１４００に含まれるインデクスの中から、問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択する。第２のインデクスグループ１４００には、第２のユーザアプリケーション１１００を開発している時にチューニングを行った際に定義したインデクスのみが存在しており、第２のユーザアプリケーション１１００の開発者の意図したとおり、第２のインデクス１９００（図示のＩＤＸ＿Ｂに相当）が選択される。
【００３９】
データベース管理プログラムは、第２のインデクス１９００を利用する第２のユーザアプリケーション１１００のためのアクセスパス１７００を生成する。その後、データベース管理プログラムは、このアクセスパス１７００を実行して、実際にデータベースにアクセスする。第２のユーザアプリケーション１１００のアクセスパス１７００には１つの操作（第３の操作）が示されており、当該第３の操作が実行される。第３の操作では、データベース管理プログラムが、アクセスパスを生成した際に選択した第２のインデクス１９００にアクセスし、所属コードごとのグループ化を計算して行数をカウントする。以上のように、データベース管理プログラムは、第２のユーザアプリケーション１１００の問い合わせに対する結果２２００を求める。
【００４０】
次に、本実施の形態に対する比較例について説明する。この比較例では、第１及び第２のユーザアプリケーション１０００，１１００のアクセスパスを生成する際に、インデクス定義情報１５００の全てのインデクスの中から、問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択する。この比較例では、それぞれのユーザアプリケーション開発時にチューニングを行った際に定義したインデクス以外のインデクスが存在している。しかし、インデクスは全てのユーザアプリケーションにとって問い合わせ結果を求める際の性能が最も良くなる訳ではない。第１のユーザアプリケーション１０００には第1のインデクス１８００、第２のユーザアプリケーション１１００には第２のインデクス１９００というように、それぞれのユーザアプリケーションごとに問い合わせ結果を求める際の性能が最も良いインデクスが必要となる。そのため、例えば、第１のユーザアプリケーション１０００を実行した際に、第１のユーザアプリケーション１０００の開発者が意図していない第２のインデクス１９００が選択されてアクセスパスが生成される場合がある。すると、実際にデータベースにアクセスする手順（アクセスパスに相当）が変化するため、第１のユーザアプリケーション１０００はその開発者が意図している性能では動作せず、性能が低下する。
【００４１】
以上のように、本実施の形態では、従来のように単に全てのインデクスの中から問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択する場合と比較すると、選択対象とするインデクスを限定することが可能となる。そのため、本実施の形態によれば、他のユーザアプリケーションのアクセスパスに影響を与えることなく、ユーザアプリケーションごとに問い合わせ結果を求める際の性能が最も良いアクセスパスを生成するためのインデクスを自由に追加、変更又は削除することができる。これによって、本実施の形態によれば、ユーザアプリケーションを開発した時に、他のユーザアプリケーションのアクセスパスへの影響確認にかかる工数の削減を行うことができる。本実施の形態の概念は以上であるが、次にさらに詳細な概念について説明する。
【００４２】
図２は、インデクスグループの概念を説明するための図であり、各図を用いて、第１及び第２のインデクスグループ１３００，１４００について具体的に説明する。図２では、左側に社員表２０００が示されており、右上に、第１のインデクス１８００が所属する第１のインデクスグループ１３００が示されており、右下に、第２のインデクス１９００が所属する第２のインデクスグループ１４００が示されている。この社員表２０００には、氏名列２０２及び所属コード列２０３の組に定義された、第１のインデクス１８００（ＩＤＸ＿Ａ）、及び、所属コード列２０３に定義された第２のインデクス１９００（ＩＤＸ＿Ｂ）が存在している。
【００４３】
第１及び第２のインデクス１８００，１９００の両方が所属コード列２０３のデータに対するインデクスとなっている。本実施の形態では、複数のインデクスをそれぞれ第１及び第２のインデクスグループ１３００，１４００に所属させるために、インデクスグループを指定することによりアクセスパス生成の際に選択されるインデクスを指定している。
【００４４】
（２）本実施の形態におけるデータベース管理装置の構成
図３は、データベース管理装置３４００を含むデータ処理システムの構成の一例を示す。データ処理システムは、ホストコンピュータ３１００、端末３２００、データベース管理装置３４００及び外部記憶装置３５００を備える。これらホストコンピュータ３１００、端末３２００、データベース管理装置３４００及び外部記憶装置３５００は、ネットワーク３３００を介して接続されている。
【００４５】
ホストコンピュータ３１００では、ユーザアプリケーション３０００（上記第１及び第２のユーザアプリケーション１０００，１１００）が動作している。ユーザアプリケーション３０００は、ネットワーク３３００を介してデータベース管理装置３４００に対して、リレーショナルデータモデルのデータベースに対する問い合わせ言語であるＳＱＬを発行することでデータベースに対する問い合わせを行う。問い合わせの結果は、データベース管理装置３４００から、ネットワーク３３００を介してホストコンピュータ３１００のユーザアプリケーション３０００に返される。ユーザアプリケーション３０００は、データベース管理装置３４００から受け取った問い合わせ結果を加工して利用する。
【００４６】
端末３２００は、ネットワーク３３００を介してデータベース管理装置３４００に対し、ＳＱＬを発行することで定義要求を行う。この定義要求には、表３５５０の追加、変更若しくは削除、インデクス３５６０（上記インデクス１８００，１９００に相当）の追加、変更若しくは削除、又は、インデクスグループの追加、変更若しくは削除などが存在する。定義要求の実行結果は、データベース管理装置３４００からネットワーク３３００を介して端末３２００に返される。
【００４７】
データベース管理装置３４００は、プロセッサ３４１０、メモリ３４２０、ネットワークインターフェース３４５０及びバス３４４０を備えている。プロセッサ３４１０及びメモリ３４２０は、バス３４４０の一部としての内部バスで接続されている。メモリ３４２０にはプログラム及びその他データなどが記憶されている。プロセッサ３４１０は、メモリ３４２０に記憶されているデータベース管理プログラム３４３０などのプログラムを実行する。
【００４８】
メモリ３４２０は、プログラム及びデータを記憶する記憶媒体である。具体的には、メモリ３４２０には、データベース管理プログラム３４３０が記憶されるとともに、データベース管理プログラム３４３０が生成するアクセスパス３４２１が記憶される。
【００４９】
データベース管理プログラム３４３０は、表３５５０及びインデクス３５６０を管理する。表３５５０は、概念的に表形式で表現されるデータの集まりであり、インデクス３５６０は、当該データを効率的にアクセスするための手段である。データベース管理プログラム３４３０は、定義要求受付部３４３１、データベース（以下「ＤＢ」ともいう）アクセス要求受付部３４３２、ディクショナリ管理部３４３３、アクセスパス生成部３４３４、アクセスパス実行部３４３５及びアクセスパス表示部３４３６を有する。
【００５０】
定義要求受付部３４３１は、端末３２００などからの定義要求を受け付けて、データベース管理プログラム３４３０全体を制御する。具体的には、定義要求受付部３４３１は、端末３２００などから要求された表３５５０の追加、変更若しくは削除、インデクス２５６０の追加、変更若しくは削除、又は、インデクスグループの追加、変更若しくは削除などの定義の変更要求を解析する。その後、定義要求受付部３４３１は、要求に応じて、ディクショナリ管理部３４３３に処理を要求する。
【００５１】
即ち、定義要求受付部３４３１は、端末３２００などから受け取った、ＳＱＬによる定義要求を解析して、ディクショナリ管理部３４３３が実施するべき処理の内容を把握し、ディクショナリ管理部３４３３に処理を要求する。その後、定義要求受付部３４３１は、定義要求に対する処理の実行結果を、要求元である端末３２００に返す。
【００５２】
ＤＢアクセス要求受付部３４３２は、ユーザアプリケーション３０００からのＤＢアクセス要求を受け付けて、データベース管理プログラム３４３０全体を制御する。具体的には、ＤＢアクセス要求受付部３４３２は、ユーザアプリケーション３０００などから要求されたＤＢアクセス要求を解析し、データベースに対する操作の実行手順を生成するために、アクセスパス生成部３４３４に処理を要求する。次にＤＢアクセス要求受付部３４３２は、アクセスパス生成部３４３４が出力したアクセスパス３４２１を実行して、実際にデータベースにアクセスを行うために、アクセスパス実行部３４３５に処理を要求する。その後、ＤＢアクセス要求受付部３４３２は、ＤＢアクセス要求に対する処理の実行結果を、要求元であるユーザアプリケーション３０００に返す。
【００５３】
ディクショナリ管理部３４３３は、インデクス管理表３５２０、インデクスグループ管理表３５３０、インデクス−インデクスグループ対応表３５４０及びデータベースを構成する論理的なスキーマ構造、並びにテーブル情報などの各種定義情報を管理する機能を有する。具体的には、ディクショナリ管理部３４３３は、表３５５０に対応する定義情報、インデクス３５６０に対する定義情報（インデクス管理表３５２０）、及び、インデクスグループに対する定義情報（インデクスグループ管理表３５３０、インデクス−インデクスグループ対応表３５４０）を管理する。
【００５４】
また、ディクショナリ管理部３４３３は、上記定義要求がされた場合、定義要求受付部３４３１から要求を受信して解析した結果を、インデクス管理表３５２０、インデクスグループ管理表３５３０及びインデクス−インデクスグループ対応表３５４０などに記録する。さらに、ディクショナリ管理部３４３３は、ＤＢアクセスが要求された場合、ＤＢアクセス要求受付部３４３２からの要求に基づいて、アクセスパス生成部３４３４が処理を実行する際に必要となる定義情報を提供する。
【００５５】
アクセスパス生成部３４３４は、ＤＢアクセス要求があった場合に、アクセスパスの生成を行う機能を有する。具体的には、アクセスパス生成部３４３４は、表３５５０及びインデクス３５６０にアクセスするための適切なアクセスパスを生成する。生成されたアクセスパスはメモリ３４２０に出力される。
【００５６】
アクセスパス実行部３４３５は、ＤＢアクセス要求があった場合に、アクセスパス生成部３４３４が生成したメモリ３４２０に出力したアクセスパス３４２１で決められた実行手順に従い、実際にデータベースへのアクセスを実行する。具体的には、アクセスパス実行部３４３５は、表３５５０及びインデクス３５６０にアクセスして、ＤＢアクセス要求に対する実行結果を求める機能を有する。
【００５７】
アクセスパス表示部３４３６は、アクセスパス生成部３４３４が生成してメモリ３４２０に出力したアクセスパス３４２１で決められた実行手順を確認するために、アクセスパスを表示する機能を有する。
【００５８】
上述したメモリ３４２０に配置される各処理部３４３１などは、プログラムで実現することを想定しているが、その代わりに、オブジェクト又はハードウェアで実現することも可能である。メモリ３４２０に配置した各処理部３４３１などは、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）又はＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）のような記憶媒体に格納されており、ＯＳ（Operating System）又はデータベースシステムが有するインストール処理部によりメモリ３４２０にインストールされる。
【００５９】
外部記憶装置３５００は、環境定義ファイル３５１０、インデクス管理表３５２０、インデクスグループ管理表３５３０、インデクス−インデクスグループ対応表３５４０、表データ３５５０及びインデクス３５６０を記憶している。外部記憶装置３５００は、例えば磁気的にデータが記憶される磁気ディスクを搭載する記憶装置である。
【００６０】
環境定義ファイル３５１０は、データベース管理プログラム３４３０の動作をカスタマイズするための設定が記録されている。環境定義ファイル３５１０は、データベース管理プログラム３４３０を構築する際に作成される。環境定義ファイル３５１０は、例えばテキストで記述されたファイルである。
【００６１】
環境定義ファイル３５１０の内容は、データベース管理プログラム３４３０の起動時に、データベース管理システムが管理する環境定義ファイルの設定値を記録するための表（図示せず）に記録される。データベース管理プログラム３４３０は、動作している間には環境定義ファイル３５１０を直接参照せずに、環境定義ファイル３５１の設定値を記録した上記図示しない表から設定値を取得する。インデクス管理表３５２０、インデクスグループ管理表３５３０、インデクス−インデクスグループ対応表３５４０、表データ３５５０及びインデクス３５６０については後述する。
【００６２】
図４は、インデクスグループ管理表３５３０を構成する列情報の一例を示す。インデクスグループ管理表３５３０は、定義されたインデクスグループごとに１レコードとする表形式となっている。インデクスグループは、表又はインデクスに関係なく定義することができる。インデクスグループ管理表３５３０には、インデクスグループＩＤ４０１及びインデクスグループ名４０２を含んでいる。インデクスグループＩＤ４０１は、インデクスグループ名４０２ごとに一意に割り当てられる識別子である。なお、インデクスグループ名４０２に関して「ＩＤＸＧＲＰ＿Ａ」は、上記第１のインデクスグループ１３００を表しており、「ＩＮＤＧＲＰ＿Ｂ」は、上記第２のインデクスグループ１４００を表している。インデクスグループ管理表３５３０は、後述するインデクスグループ定義要求の例に対応している。具体的な対応関係については、図５において説明する。
【００６３】
図５は、インデクスグループを作成するためのインデクスグループの定義要求の一例を示す。インデクスグループの定義要求は、ＳＱＬにより記述されている。当該インデクスグループの定義要求は、インデクスグループ名が「ＩＤＸＧＲＰ＿Ａ」であるインデクスグループを定義することを示している。ここで云うインデクスグループは、上記第１のインデクスグループ１３００に相当する。
【００６４】
上述したインデクスグループ管理表３５３０は、図５に示したインデクスグループの定義要求の例に対応している。インデクスグループ管理表３５３０の１番目のレコード４０３は、インデクスグループ名が「ＩＤＸＧＲＰ＿Ａ」であり、図５に示すインデクスグループの定義要求に記述されたインデクスグループ名「ＩＤＸＧＲＰ＿Ａ」と対応している。また、図５に示すインデクスグループに対応する、インデクスグループの削除要求も実現可能である。
【００６５】
図６は、インデクス管理表３５２０を構成する列情報の一例を示す。インデクス管理表３５２０は、定義されたインデクスを構成する列ごとに１レコードとする表形式となっている。インデクス管理表３５２０は、列情報として、インデクスＩＤ６０１、インデクス名６０２、表名６０３、インデクス構成列名６０４及びバージョン６０５を含む。
【００６６】
表名６０３は、当該インデクスが定義された表の名称を表している。インデクス構成列名６０４は、当該インデクスが定義された表の列名を表している。バージョン６０５は、当該インデクスのバージョンを表している。
【００６７】
バージョン６０５が存在することで、同一名称のインデクス名６０２で、異なる実体のインデクスを作成することが可能となる。インデクス名６０２は、全てのインデクス３５６０の間においてユニークなものであったのが、これにより、同一の名称ながらバージョン６０５を変更して１つ以上のインデクスグループに所属することができるようになる。
【００６８】
このように本実施の形態においては、あるインデクスをインデクスグループＡ，Ｂの両方にも所属することができる。ここで、インデクスグループＡを利用して動作している第１のユーザアプリケーション１０００と、インデクスグループＢを利用して動作している第２のユーザアプリケーション１１００とが存在する場合を考える。
【００６９】
インデクスを複数のインデクスグループに所属させるために当該バージョンの概念を用いない場合には、例えば、第１のユーザアプリケーション１０００の性能を改善するためにそのアクセスパスを変更しようとして第１のインデクス１８００の定義を変更したいとき、直接、第１のインデクス１８００を変更してしまうと、第２のユーザアプリケーション１１００のアクセスパスにも変化が生じてしまう可能性がある。従って、あるインデクスの変更に伴う影響がその所属するインデクスグループ以外のインデクスグループに広がってしまう。
【００７０】
そこで本実施形態では、複数のインデクスグループに所属している第１のインデクス１８００を変更する場合には、バージョンを変えた同名の第１のインデクス１８００を作成する。一例として、インデクスグループＡに所属している第１のインデクス１８００のバージョンを「２」として、インデクスグループＢに所属している第１のインデクス１８００のバージョンを「１」とする。
【００７１】
本実施の形態では、第２のインデクスグループ１４００に所属している第１のインデクス１８００（バージョン１）には変更をせず、新たに作成した第１のインデクス１８００（バージョン２）に対して変更を加えることにより、次のような利点がある。即ち、このようにすると、第１のインデクスグループ１３００を利用して動作している第１のユーザアプリケーション１０００の性能改善を実現しながらも、第２のユーザアプリケーション１１００のアクセスパスに影響を与えないようにすることができる。
【００７２】
図７は、インデクス−インデクスグループ対応表３５４０を構成する列情報の一例を示す。このインデクスーインデクスグループ対応表３５４０においては、プロセッサ３４１０によりインデクスグループとインデクスとの対応関係が定義されている。即ち、インデクス−インデクスグループ対応表３５４０は、定義されたインデクスと、当該インデクスの所属するインデクスグループの関係ごとに１レコードとする表形式となっている。１つのインデクスは複数のインデクスグループに所属することができる。インデクス−インデクスグループ対応表３５４０は、列情報としてインデクスＩＤ８０１及びインデクスグループＩＤ８０２を含む。インデクスＩＤ８０１は、インデクスごとに一意に割り当てられている識別子である。インデクスグループＩＤ８０２は、当該インデクスが所属しているインデクスグループに一意に割り当てられる識別子である。
【００７３】
また、図７に示すインデクス−インデクスグループ対応表３５４０は、図８において後述するインデクス定義要求の例に対応している。具体的な対応関係については、図８において後述する。
【００７４】
図８は、インデクスを作成するためのインデクスの定義要求の一例を示す図である。このインデクスの定義要求もＳＱＬによって記述されている。インデクスの定義要求は、社員表２０００の列である氏名列２０２及び所属コード列２０３に対し、インデクスを定義して、第１のインデクスグループ１３００（ＩＤＸＧＲＰ＿Ａ）というインデクスグループに所属させるというインデクスの定義要求を示している。
【００７５】
このインデクス定義要求は、インデクス名が「ＩＤＸ＿Ａ」というインデクスを定義することを、「ＣＲＥＡＴＥ」から「ＩＤＸ＿Ａ」までの部分で示している。そして、社員表２０００の氏名２０２列、及び、所属コード２０３列に対してインデクスを定義することを、「ＯＮ」から「ＩＮＤＥＸＧＲＯＵＰ」の手前までの部分で示している。また、「ＩＮＤＥＸＧＲＯＵＰ」以降の部分は、定義したインデクスを所属させるインデクスグループ名を表している。さらに、このインデクス定義要求は、図５に示したインデクスグループ定義要求に基づいて作成済みのインデクスグループ名を指定している。
【００７６】
図６に示すインデクス管理表３５２０、及び、図７に示すインデクス−インデクスグループ対応表３５４０は、上述のように図８に示すインデクス定義要求の例に対応する。図６に示すインデクス管理表３５２０における１番目のレコード６０６及び２番目のレコード６０７を参照すると、インデクス名が「ＩＤＸ＿Ａ」であるインデクスは、表名「Ｅｍｐｌｏｙｅｅ」及び列名「ＮＡＭＥ」、「ＤＩＶＩＳＩＯＮ」である。
【００７７】
従って、レコード６０６及びレコード６０７が、図８に示したインデクス定義要求に対応していることが分かる。そして、図７に示したインデクス−インデクスグループ対応表３５４０の１番目のレコード８０３を参照すると、インデクスＩＤが「１」であるインデクスと、インデクスグループＩＤが「１」であるインデクスグループが対応付けられている。インデクスＩＤが「１」であるインデクスは、図６に示すインデクス管理表３５２０に基づいて「ＩＤＸ＿Ａ」であることが分かる。さらに、インデクスグループＩＤが「１」であるインデクスグループは、インデクスグループ管理表３５３０に基づいて「ＩＤＸＧＲＰ＿Ａ」であることが分かる。このため、インデクス１８００（ＩＤＸ＿Ａ）がインデクスグループ１３００（ＩＤＸＧＲＰ＿Ａ）に所属していることを示している。
【００７８】
ここで、インデクス変更要求をするには、図８に示すインデクス定義要求を記述したＳＱＬ文において用いられていた「ＣＲＥＡＴＥ」の代わりに「ＡＬＴＥＲ」を用いることにより実現が可能である。また、インデクス削除要求をするには、上記インデクス定義要求を記述したＳＱＬ文において用いられている「ＣＲＥＡＴＥ」の代わりに「ＤＥＬＥＴＥ」を用いることにより実現が可能である。
【００７９】
また、インデクス定義要求によって、インデクスを新規作成する場合にインデクスグループに所属させる以外にも、既存のインデクスを、別のインデクスグループにも所属させるインデクス追加要求も実現可能である。
【００８０】
（３）本実施の形態におけるデータベース管理方法
図９は、データベース管理プログラム３４３０がインデクスグループを利用する際の手順を示す。データベース管理プログラム３４３０は、データベース管理装置１２００においてプロセッサによって動作が制御されている。以下では、各ステップを実行する主体として、プロセッサの代わりに主としてデータベース管理プログラム３４３０（又はその各機能モジュール）を挙げて説明する。ステップＳ９０１では、定義要求受付部４３４１が、端末３２００などによって発行されたインデクスグループ定義要求及びインデクス定義要求を受信し、解析を行う。その後、ディクショナリ管理部３４３３が、その解析結果に基づいて呼び出され、要求に基づいた定義を実行する。インデクスグループ定義要求及びインデクス定義要求の手順については、それぞれ後述する図１０及び図１１において後述する。
【００８１】
ステップＳ９０２では、ディクショナリ管理部３４３３が、ユーザアプリケーション（以下、「ＵＡＰ」とも省略する）と、当該ユーザアプリケーションの利用するインデクスが所属しているインデクスグループの対応付けを行う。ユーザアプリケーションの対応付けは、環境定義ファイル３５１０において指定される。
【００８２】
具体的には、例えば、環境定義ファイル３５１０の記述形式に「ＩＮＤＥＸ  ＧＲＯＵＰ  ユーザアプリケーション名＝インデクスグループ名」という、インデクスグループとユーザアプリケーションとの対応付けを指定するための記述を新たに設け、「ＩＮＤＥＸ  ＧＲＯＵＰ  ＵＡＰ１＝ＩＤＸＧＲＰ＿Ａ」と記述することで、第１のユーザアプリケーション１０００（ＵＡＰ１に相当）と第１のインデクスグループ１３００とが対応付けされる。
【００８３】
なお、従来のＤＢＭＳで動作していたユーザアプリケーションを本実施の形態のデータベース管理装置１２００で利用する場合（又は、例えば、仮にインデクスグループを複数用意する必要がない場合）においては、本実施の形態を採用しないＤＢＭＳと同様に利用したいことも考えられる。具体例としては、例えば、インデクス定義要求において、インデクスグループの指定を省略したいとき、又は、ユーザアプリケーションを開発するたびにインデクスグループとの対応関係を記述したくないときなどである。
【００８４】
そこで、環境定義ファイル３５１０の記述形式に「ＤＥＦＡＵＬＴ  ＩＮＤＥＸ  ＧＲＯＵＰ  インデクスグループ名」というような、インデクスグループの指定を省略した場合に仮定されるインデクスグループを指定するための記述形式を新たに設けて、「ＤＥＦＡＵＬＴ  ＩＮＤＥＸ  ＧＲＯＵＰ  ＩＤＸＧＲＰ＿ＤＥＦＡＵＬＴ」と記述することで、インデクスグループの指定を省略した場合に「ＩＤＸＧＲＰ＿ＤＥＦＡＵＬＴ」が仮定されるように対応付けを行うことも可能である。
【００８５】
環境定義ファイル３５１０の内容は、このようなファイル形式とする代わりに、データベース管理プログラム３４３０の起動時に、データベース管理プログラム３４３０が管理する環境定義ファイルの設定値を記録するための表（図示せず）に記録されるようにしても良い。このような構成では、データベース管理プログラム３４３０は、動作している間、環境定義ファイル３５１０を直接参照せずに、環境定義ファイルの設定値を記録するための図示しない表から設定値を取得する。従って、端末３２００などが、データベース管理プログラム３４３０に対し、ＳＱＬを利用して環境定義ファイル３５１０の設定値を記録するための表（図示せず）の変更要求を行うことで、ユーザアプリケーションとインデクスグループの対応付けを変更することも可能である。
【００８６】
なお、本実施の形態では、このような環境定義ファイル３５１０を利用する代わりに、ユーザアプリケーションとインデクスグループの対応関係を記録するためのユーザアプリケーション−インデクスグループ対応表（図示せず）などを外部記憶装置３５００に用意しておき、ユーザアプリケーションとインデクスグループの対応関係を管理するようにしても良い。
【００８７】
ここで、上述のような環境定義ファイル３５１０又はユーザアプリケーション−インデクスグループ対応表（図示せず）などを利用して、ユーザアプリケーションとインデクスグループの対応関係を示すことのメリットとしては、既存のユーザアプリケーション又はＳＱＬを直接変更する必要がないことである。本実施の形態を採用しないデータベース管理装置１２００を用いている場合においてユーザアプリケーション又はＳＱＬに変更を加えようとすると、ユーザアプリケーションの開発現場では、ユーザアプリケーション開発時に行ったテストを全てやり直さなければならない。このような構成によれば、環境定義ファイル３５１０又はユーザアプリケーション−インデクスグループ対応表（図示せず）などを利用して、ユーザアプリケーションとインデクスグループの対応関係を示すことによって、既存のユーザアプリケーション又はＳＱＬについて修正を行うことなく、本実施の形態におけるデータベース管理装置１２００を導入すること、又は、対応するインデクスグループを変更することが可能となる。
【００８８】
次にステップＳ９０３では、アクセスパス表示部３４３６が、アクセスパス生成部３４３４が生成したアクセスパス３４２１を所定の形式で出力する。このような形式としては、ユーザアプリケーションの開発者が理解することができる形式であればどのような出力内容であっても良い。このような出力内容の一例としては後述する図１３に示す内容を挙げることができる。この図１３の内容の詳細については後述する。
【００８９】
アクセスパス表示部３４３６は、アクセスパスの表示要求がなされた場合、アクセスパスを表示する。併せてアクセスパス表示部３４３６は、このアクセスパスとともにインデクスグループを表示する。このアクセスパスは、このインデクスグループに所属するインデクスを利用して生成されたアクセスの手順である。このようにアクセスパスを表示する用途としては、ユーザアプリケーションを開発した際における、又は、性能改善のための調査を行う場合を挙げることができる。なお、アクセスパス表示部３４３６は、ユーザアプリケーションがサービスを提供している間は、通常、このようなアクセスパスを表示しない。
【００９０】
ステップＳ９０４では、アクセスパス実行部３４３５が、アクセスパス３４２１に従ってデータベースにアクセスを行い、問い合わせ要求に対する回答を作成してユーザアプリケーション１０００などに返す。このような回答としては、図１に示す実行結果２１００，２２００を挙げることができる。
【００９１】
＜インデクスグループ作成ステップ＞
インデクスグループ作成ステップでは、インデクスとインデクスグループの対応付けを行い、その対応関係を保持する。インデクスとインデクスグループの対応付けについては、ユーザからの定義要求に基づいて行うが、その具体的な一例について図１０及び図１１を用いて以下に説明する。
【００９２】
図１０は、データベース管理プログラム３４３０がインデクスグループを定義する際における処理の手順を示す。本処理は、プロセッサ３４１０により定義要求受付部３４３１が実行されることによって、開始される。このインデクスグループ作成ステップでは、プロセッサが複数のインデクスをグループ化することによりインデクスグループを作成する。
【００９３】
プロセッサ３４１０は、まず、定義要求受付部３４３１を実行する。この要求受付部３４３１は、端末３２００などによって入力されたインデクスグループ定義要求から、定義対象であるインデクスグループのインデクスグループ名を取得し、メモリ３４２０に保持する（ステップＳ１００１）。例えば、図５に示したインデクスグループ定義要求が入力された場合、メモリ３４２０には、定義対象のインデクスグループ名である「ＩＤＸＧＲＰ＿Ａ」が保持される。
【００９４】
プロセッサ３４１０は、その後、ディクショナリ管理部３４３３を実行する。このディクショナリ管理部３４３３は、メモリ３４２０に保持されているインデクスグループ名、及び、インデクス名ごとにユニークな値をインデクスグループＩＤとして関連付けて、インデクスグループ管理表３５３０に登録する（ステップＳ１００２）。例えば、図５に示すインデクスグループ定義要求が入力された場合には、図４に示すレコード４０３が登録される。
【００９５】
図１１は、データベース管理プログラム３４３０がインデクスを新たに定義する際の処理の手順を示すフローチャートである。本処理は、プロセッサ３４１０により定義要求受付部３４３１が実行されることによって、開始される。
【００９６】
定義要求受付部３４３１は、端末３２００などによって入力されたインデクス定義要求から、定義対象であるインデクスのインデクス名、当該インデクスに含まれる列が所属している表名、インデクスに含まれる列名、及び、当該インデクスを所属させるインデクスグループ名を取得し、メモリ３４２０に保持する（ステップＳ１１０１）。
【００９７】
例えば、図８に示したインデクス定義要求が入力された場合には、定義対象のインデクス名である「ＩＤＸ＿Ａ」、当該インデクスに含まれる列が所属している表名である「Ｅｍｐｌｏｙｅｅ」、インデクスに含まれる列名である「ＮＡＭＥ」及び「ＤＩＶＩＳＩＯＮ」、及び、当該インデクスを所属させるインデクスグループ名である「ＩＤＸＧＲＰ＿Ａ」が保持される。
【００９８】
次にプロセッサ３４１０は、ディクショナリ管理部３４３３を実行することによって、メモリ３４２０に保持されているインデクス名、表名、列名、及び、インデクスごとにユニークな値をインデクスＩＤとするとともに、さらにバージョンを「０」として関連付けて、インデクス管理表３５２０に登録する（ステップＳ１１０２）。列名は複数指定することができる。列名が複数指定されていた場合には、列名ごとに１つの関連付けを作成して、それぞれ登録する。例えば、図８に示したインデクス定義要求が入力された場合には、図６に示したレコード６０６及びレコード６０７が登録される。
【００９９】
その後、ディクショナリ管理部３４３３は、インデクスグループ管理表３５３０を参照して、メモリ３４２０に保持されているインデクスグループ名に対応するインデクスグループＩＤを取得する。このインデクスＩＤと、インデクスごとにユニークな値として付与したインデクスＩＤを関連付けて、インデクス−インデクスグループ対応表３５４０に登録する（ステップＳ１１０３）。例えば、図８に示したインデクス定義要求が入力された場合には、図４に示したレコード４０３から、インデクスグループ名「ＩＤＸＧＲＰ＿Ａ」に対応するインデクスＩＤである「１」を取得し、インデクスごとにユニークな値として付与したインデクスＩＤである「１」と関連付けて、図７に示したレコード８０３が登録される。
【０１００】
本実施形態では、インデクスグループ作成方法の具体的な一例として、インデクスグループを定義したあとで、インデクスグループを指定してインデクスを定義するインデクスグループ作成方法について説明したが、別の一例として、既存の１つ以上のインデクスから新たなインデクスグループを作成する方法もある。例えば、既存のインデクスとして、インデクス１、インデクス２及びインデクス３が存在している場合、この３つのインデクスからＩＤＸＧＲＰ＿ＮＥＷというインデクスグループを作成する場合について説明する。これを実現するためのインデクスグループ定義要求（ＳＱＬ）としては、「ＣＲＥＡＴＥ  ＩＮＤＥＸＧＲＯＵＰ  ”ＩＤＸＧＲＰ＿ＮＥＷ”  ＦＲＯＭ  ”インデクス１”，”インデクス２”，”インデクス３”」などが考えられる。
【０１０１】
このとき、定義要求受付部３４３１は、端末３２００などによって入力された前述したインデクスグループ定義要求から、定義対象であるインデクスグループ名、及び、所属させるインデクス名を取得し、メモリ３４２０に保持する。
【０１０２】
次にプロセッサ３４１０は、ディクショナリ管理部３４３３を実行することによって、メモリ３４２０に保持されているインデクスグループ名にユニークな値をインデクスグループＩＤとして、インデクスグループ管理表３５３０に登録する。
【０１０３】
その後、ディクショナリ管理部３４３３は、インデクス管理表３５２０を参照して、メモリ３４２０に保持されているインデクス名に対応するインデクスＩＤを取得する。このインデクスＩＤと、インデクスグループごとにユニークな値として付与したインデクスグループＩＤを関連付けて、インデクス−インデクスグループ対応表３５４０に登録する。
【０１０４】
＜アクセスパス作成ステップ＞
図１２は、データベース管理プログラム３４３０がアクセスパスを生成する際の処理の手順を示す。本処理は、プロセッサ３４１０によってＤＢアクセス要求受付部３４３２が実行されることにより、開始される。このアクセスパス作成ステップでは、ＤＢアクセス要求受付部３４３２が、インデクスグループの指定されたアクセス要求を受け付け、インデクスグループに含まれるインデクスの中から問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択し、そのインデクスを利用してアクセスパスを生成する。
【０１０５】
具体的には、まず、ＤＢアクセス要求受付部３４３２は、いずれかのユーザアプリケーション１０００などから、インデクスグループの指定されたＤＢアクセス要求を受け付ける。次にＤＢアクセス要求受付部３４３２は、ＤＢアクセス要求を発行したユーザアプリケーション３０００に関連付けられているインデクスグループ名を、環境定義ファイル３５１０で指定された設定値を参照して取得する（ステップＳ１２０１）。
【０１０６】
次にプロセッサ３４１０はディクショナリ管理部３４３３を実行する。ディクショナリ管理部３４３３は、インデクスグループ管理表３５３０を参照して、上記ステップＳ１２０１において取得されたインデクスグループ名に対応するインデクスグループＩＤを取得する。ディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照して、そのインデクスグループＩＤに対応するインデクスＩＤを取得する。その後、ディクショナリ管理部３４３３は、インデクス管理表３５２０を参照して、そのインデクスＩＤに対応するインデクス情報を取得してメモリ３４２０に保持する（ステップＳ１２０２）。
【０１０７】
次にプロセッサ３４１０は、ＤＢアクセス要求受付部３４３２を実行する。ＤＢアクセス要求受付部３４３２は、ユーザアプリケーション３０００によって入力されたＤＢアクセス要求から、データを検索する際の条件となる列名及び表名、並びに、射影対象である列名及び表名を取得する（ステップＳ１２０３）。なお、このユーザアプリケーション３０００は、上述した第１及び第２のユーザアプリケーション１０００，１１００を総称したものである。
【０１０８】
次にプロセッサ３４１０は、アクセスパス生成部３４３４を実行する。アクセスパス生成部３４３４は、上述のようにメモリ３４２０に保持しているインデクス情報と、ステップＳ１２０３で取得した表名や列名とを照らし合わせ、実際にデータベースにアクセスする際に利用するのに適したインデクスとして、問い合わせ結果を求める際の性能が最も良いインデクスを決定する。そして、アクセスパス生成部３４３４は、当該インデクスを利用したアクセスパスを生成し、このアクセスパスをメモリ３４２０に保持させる（ステップＳ１２０４）。
【０１０９】
＜アクセスパス表示ステップ＞
図１３は、データベース管理プログラム３４３０がアクセスパスを出力した場合における出力内容の一例を示す。図示の例では、第１のユーザアプリケーション１０００によるＤＢアクセス要求が行われた際に出力されたアクセスパスの一例を示す。このアクセスパス表示ステップでは、プロセッサ３４１０が、アクセスパス表示部３４３６を実行し、インデクスグループに所属するインデクスを利用して生成されたアクセスパスとともにそのインデクスグループを含めて表示装置（図示せず）に表示する。
【０１１０】
具体的には、その出力内容としては、第１行目から第４行目には、第１のユーザアプリケーション１０００が発行したＤＢアクセス要求を示すＳＱＬが出力される。第６行目には、第１のユーザアプリケーション１０００に対応付けられたインデクスグループ名が出力される。なお、第５行目は、その下の第６行目の内容がインデクスグループである旨のタイトルを表している。第８行目以降は、データベースのデータにアクセスする手順が出力される。なお、第７行目は、その下の第８行目以降の内容がアクセスパスである旨のタイトルを表している。
【０１１１】
「１：ＳＥＬＥＣＴ  ＳＴＡＴＥＭＥＮＴ」の部分は、当該ＳＱＬがＳＥＬＥＣＴ文であることを示している。「２：！ＳＣＡＮ」の部分は、当該ＳＱＬが、最小値、最大値、集合関数値、結合検索を含まない単純なＳＱＬであることを示す。「３：！ＴＡＢＬＥ  Ｅｍｐｌｏｙｅｅ」の部分は、検索対象の表名を示す。「４：！ＩＮＤＥＸ  ＩＤＸ＿Ａ［１］（２）」の部分は、当該アクセスパスがインデクスを利用した検索であることを示す。さらに当該部分は、利用するインデクス名が「ＩＤＸ＿Ａ」であり、バージョンが「１」であり、「ＩＤＸ＿Ａ」を構成しているインデクスを構成する列数が２であることを示す。
【０１１２】
さらに「５：！ＳＥＡＲＣＨ  ＴＹＰＥ  ＲＡＮＧＥ」の部分は、インデクスを利用する場合のアクセス方法を示す。「６：！ＳＥＡＲＣＨ  ＣＯＬＵＭＮＳ」及び「７：！ＮＡＭＥ（１）、ＤＩＶＩＳＩＯＮ（２）」の部分は、インデクスの検索条件が指定された列の列名とインデクス上での位置を示す。「８：！ＳＣＡＮ  ＴＹＰＥ  ＩＮＤＥＸ」の部分は、インデクスを利用した検索であり、かつ、表にもアクセスすることを示す。「９：！ＲＤＡＲＥＡ  ＮＵＭＢＥＲ  １」の部分は、アクセスパス実行時にアクセスするデータベースの領域の数を示す。「１０：！ＷＩＴＨ  ＳＨＡＲＥ  ＬＯＣＫ」の部分は、データベースにアクセスする際の排他の種類を示す。
【０１１３】
＜インデクス変更ステップ＞
図１４は、インデクス定義を変更する際における処理の手順を示す。インデクス変更ステップは、プロセッサ３４１０が、インデクスグループに所属するインデクスを変更する手順を表している。このインデクス変更ステップは、別のインデクス作成ステップ及び対応関係変更ステップを含んでいる。まず、概念を説明すると、上記別のインデクス作成ステップでは、プロセッサ３４１０が、インデクスが単一のインデクスグループに所属している場合にはインデクス自体を直接変更する一方、そのインデクスが複数のインデクスグループに所属している場合には、そのインデクスを複製して同一名称を用いた新規な別のインデクスを作成する。次に、上記対応関係変更ステップでは、プロセッサ３４１０が、複数のインデクスグループのうち別のインデクスが所属すべきインデクスグループと別のインデクスとの対応関係を変更する。
【０１１４】
次に、具体的に説明すると、図１４に示す処理は、プロセッサ３４１０によって定義要求受付部３４３１が実行されることによって、開始される。定義要求受付部３４３１は、端末３２００などによって入力されたインデクス変更要求から、変更対象であるインデクスのインデクス名、及び、当該インデクスが所属するインデクスグループ名を取得する（ステップＳ１４０１）。
【０１１５】
次にプロセッサ３４１０は、ディクショナリ管理部３４３３を実行することによって、インデクス管理表３５２０を参照して、ステップＳ１４０１で取得したインデクス名に対応するインデクスＩＤを取得する。
【０１１６】
同一インデクス名のインデクスが存在している可能性があるため、ディクショナリ管理部３４３３は、さらに、インデクスグループ管理表３５３０を参照して、上記ステップＳ１４０１で取得したインデクスグループ名に対応するインデクスグループＩＤを取得する。
【０１１７】
ディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照して、取得したインデクスＩＤとインデクスグループＩＤの対応が成立するインデクス−インデクスグループ情報を取得することで、変更対象のインデクスＩＤを特定する。
【０１１８】
次にディクショナリ管理部３４３３は、インデクス管理表３５２０を参照して、変更対象のインデクスＩＤに対応する、変更対象のインデクス情報を取得し、メモリ３４２０に保持する（ステップＳ１４０２）。
【０１１９】
次にディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照し、変更対象のインデクスＩＤに対応するインデクスグループＩＤを取得して、その数をカウントする（ステップＳ１４０３）。次にディクショナリ管理部３４３３は、そのステップＳ１４０３でカウントしたインデクスグループＩＤの数が「１」よりも大きかった場合には、次の処理を行う（ステップＳ１４０４）。
【０１２０】
ディクショナリ管理部３４３３は、まず、保持しているインデクス情報に対して、バージョンの変更、及び、インデクスごとにユニークなＩＤを再度設定して、インデクス管理表３５２０に新たに登録する（ステップＳ１４０５）。このようにしたのは、インデクス名が同一でも、バージョンが異なるインデクスは、インデクスの実体が異なるため、インデクスＩＤも再度割り当てる必要があるためである。
【０１２１】
次にステップＳ１４０５では、ディクショナリ管理部３４３３が、インデクス管理表３５２０に登録したインデクス情報に対して、インデクス変更要求を適用する（ステップＳ１４０６）。次に、ディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照して、インデクス変更要求で指定されたインデクスグループのインデクスグループＩＤと変更対象のインデクスＩＤとの対応を表すインデクス−インデクスグループ対応情報を探す。ディクショナリ管理部３４３３は、これらのインデクスＩＤを、上記ステップＳ１４０５においてインデクス管理表に登録したインデクス情報のインデクスＩＤに変更して、インデクス−インデクスグループ管理表３５４０のデータを変更する（ステップＳ１４０７）。
【０１２２】
上記のようにインデクス情報を複製してインデクスの実体を別々にするのは、第１のインデクス１８００などの各インデクスを第１及び第２のインデクスグループ１３００，１４００の両方に所属させることができるためである。ここで、第１のインデクスグループ１３００を利用して動作している第１のユーザアプリケーション１０００と、第２のインデクスグループ１４００とを利用して動作している第２のユーザアプリケーション１１００とが存在する場合を考える。例えば、第１のユーザアプリケーション１０００の性能を改善するために、第１のユーザアプリケーション１０００のアクセスパスを変更しようと、第１のインデクス１８００の定義を変更する場合、直接、第１のインデクス１８００を直接変更してしまうと、第２のユーザアプリケーション１１００のアクセスパスが変化してしまう可能性があり、インデクス変更に伴う影響が、特定のインデクスグループ以外に広がってしまう。
【０１２３】
そこで、複数のインデクスグループに所属している第１のインデクス１８００を変更する場合には、バージョンを変えた同名の第１のインデクス１８００を作成する。一例として、第１のインデクスグループ１３００に所属している第１のインデクス１８００のバージョンを「２」として、第２のインデクスグループ１４００に所属している第１のインデクス１８００のバージョンを「１」とする。第２のインデクスグループ１４００に所属している第１のインデクス１８００（バージョン１）には変更をせず、新たに作成した第１のインデクス１８００（バージョン２）に対して変更を加えることで、インデクスグループＡを利用して動作している第１のインデクスグループ１３００の性能改善を実現して、かつ、第２のインデクスグループ１４００のアクセスパスに影響を与えないことを実現する。
【０１２４】
ステップＳ１４０４では、インデクスグループＩＤの数が「１」と等しい場合には、ディクショナリ管理部３４３３が次の処理を行う。即ち、ディスクショナリ管理部３４３３は、インデクス管理表３５２０を参照して、変更対象のインデクスＩＤに対応するインデクス情報を探し、インデクス変更要求を適用して、直接変更する（ステップＳ１４０８）。
【０１２５】
＜インデクス削除ステップ＞
図１５は、データベース管理プログラム３４３０がインデクス定義の削除を行う場合の処理の手順を示すフローチャートである。まず、概念を説明すると、インデクス削除ステップでは、プロセッサ３４１０が、インデクスグループに所属するインデクスを削除する。つまり、このインデクス削除ステップでは、プロセッサ３４１０が、削除対象のインデクスが単一のインデクスグループに所属している場合にはインデクスを直接削除し、削除対象のインデクスが複数のインデクスグループに所属している場合には、インデクス自体を削除する代わりに、インデクスグループとインデクスの対応関係を削除する。
【０１２６】
具体的に説明すると、まず、本処理は、プロセッサ３４１０により定義要求受付部３４３１が実行されることによって、開始される。定義要求受付部３４３１は、端末３２００などによって入力されたインデクス削除要求から、削除対象であるインデクスのインデクス名、及び、当該インデクスが所属するインデクスグループ名を取得する（ステップＳ１５０１）。
【０１２７】
次にプロセッサ３４１０は、ディクショナリ管理部３４３３を実行することによって、インデクス管理表３５２０を参照し、上記ステップＳ１５０１で取得したインデクス名に対応するインデクスＩＤを取得する。
【０１２８】
同一インデクス名のインデクスが存在している可能性があるため、ディスクショナリ管理部３４３３は、さらに、インデクスグループ管理表３５３０を参照して、上記ステップＳ１４０１において取得したインデクスグループ名に対応するインデクスグループＩＤを取得する。
【０１２９】
ディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照して、取得したインデクスＩＤとインデクスグループＩＤの対応が成立するインデクス−インデクスグループ情報を取得することで、削除対象のインデクスＩＤを特定する。
【０１３０】
その後、ディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照し、削除対象のインデクスＩＤに対応するインデクスグループＩＤを取得して、その数をカウントする（ステップＳ１５０２）。
【０１３１】
次にディクショナリ管理部３４３３は、上記ステップＳ１５０２においてカウントしたインデクスグループＩＤの数が「１」よりも大きかった場合には、インデクス管理表３５２０から、ステップＳ１５０２で取得した削除対象のインデクスＩＤに対応するインデクス情報を削除する（ステップ１５０４）。
【０１３２】
その後、ディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０から、インデクス削除要求で指定されたインデクスグループのインデクスグループＩＤと、削除対象のインデクスＩＤの対応を表すインデクス−インデクスグループ対応情報を探し、削除する（ステップＳ１５０５）。
【０１３３】
＜ユーザアプリケーション−インデクスグループの対応付け変更＞
図１６は、ユーザアプリケーションとインデクスグループの対応付けを変更する際における手順を示す。まず、環境定義ファイル３５１０に、対応付けを変更する対象となるユーザアプリケーションとインデクスグループとの対応付け（以下、単に「対応付け」という）が記述されているかが確認される（ステップＳ１６０１）。このステップＳ１６０１において、環境定義ファイル３５１０に、当該対応付けが記述されていない場合は、環境定義ファイル３５１０に当該対応付けを指定する記述が新たに追加される（ステップＳ１６０２）。
【０１３４】
ステップＳ１６０１において、環境定義ファイルに当該対応付けが記述されている場合は、環境定義ファイル３５１０に記述されている、当該対応付けが変更される（ステップＳ１６０３）。このように当該対応付けを変更することによって、次のような使い方を行うことができる。
【０１３５】
例えば、既にサービスを提供している第１のユーザアプリケーション１０００の性能を改善する場合を考える。なお、第１のユーザアプリケーション１０００は、第１のインデクスグループ１３００を利用して動作しているアプリケーションである。まず、さらに問い合わせ結果を求める際の性能が最も良いアクセスパスを作成するためのインデクスを考えて、第２のインデクスグループ１４００に対して、そのインデクスが定義される。次に、第２のインデクスグループ１４００を利用してアクセスパスの確認及びテストが行われる。
【０１３６】
問題がなければ、第１のユーザアプリケーション１０００と対応付けられているインデクスグループが、第１のインデクスグループ１３００から第２のインデクスグループ１４００に変更される。このようにすると、既に第１のユーザアプリケーション１０００が動作している環境においてインデクスを変更した場合にテストを行うことが可能である。さらに、このようにすると、このテストを行った際に作成したインデクスを再度定義し直す必要がなく、そのまま利用することが可能となる。
【０１３７】
＜インデクスグループ複製ステップ＞
図１７は、インデクスグループの複製が作成される場合の処理の手順を示す。まず、概念を説明すると、インデクスグループ複製ステップでは、プロセッサ３４１０が、インデクスグループを複製するとともに、そのインデクスグループに所属しているインデクスとの対応関係も複製している。
【０１３８】
具体的に説明すると、本処理は、プロセッサ３４１０によって定義要求受付部３４３１が実行されることによって、開始される。定義要求受付部３４３１は、端末３２００などによって入力されたインデクスグループ複製要求から、複製元であるインデクスグループ名及び複製先であるインデクスグループ名を取得して、保持する（ステップＳ１８０１）。次にプロセッサ３４１０は、ディクショナリ管理部３４３３を実行することによって、保持している複製先のインデクスグループ名をインデクスグループ管理表３５３０に登録する（ステップＳ１８０２）。
【０１３９】
ディクショナリ管理部３４３３は、インデクスグループ管理表３５３０を参照し、保持している複製元のインデクスグループ名に対応するインデクスグループＩＤを取得する。さらにディクショナリ管理部３４３３は、インデクス−インデクスグループ対応表３５４０を参照して、そのインデクスグループＩＤに対応するインデクス−インデクスグループ対応情報を取得する（ステップＳ１８０３）。
【０１４０】
その後、ディクショナリ管理部３４３３は、上記ステップＳ１８０３で取得したインデクス−インデクスグループ対応情報のインデクスグループＩＤを、ステップＳ１８０２で登録したインデクスグループＩＤに変更する。さらにディクショナリ管理部３４３３は、変更後のインデクス−インデクスグループ対応情報を、新たにインデクス−インデクスグループ対応表３５４０に登録する（ステップＳ１８０４）。
【０１４１】
図１８は、インデクスグループを複製するためのインデクスグループ複製要求（ＳＱＬ）の一例を示す。図示のインデクスグループ複製要求は、インデクスグループ名が「ＩＤＸＧＲＰ＿Ａ」であるインデクスグループ（第１のインデクスグループ１３００に相当）を、「ＩＤＸＧＲＰ＿ＮＥＷ」という新しいインデクスグループに複製することを示している。
【０１４２】
上述した図１７では、同一のデータベース管理プログラム３４３０において、インデクスグループを複製する場合を示した。しかしながら、インデクスグループを指定して、インデクス定義情報をファイルなどにエクスポートすることによって、別のデータベース管理システムに対して、インデクスグループの複製を作成することも可能である。
【０１４３】
このように当該インデクスグループを複製することによって、次のような使い方を行うことができる。
【０１４４】
例えば、既にサービスを提供している第１のユーザアプリケーション１０００の性能を改善する場合を考える。なお、第１のユーザアプリケーション１０００は、第１のインデクスグループ１３００を利用して動作しているアプリケーションである。まず、インデクスグループを複製して、第１のインデクスグループ１３００と同じインデクスが所属する第２のインデクスグループ１４００を作成する。次に、第２のインデクスグループ１４００に対してインデクスの追加、変更又は削除を行うことで、性能を改善する。そして第２のインデクスグループ１４００利用してアクセスパスの確認及びテストが行われる。問題がなければ、前述のユーザアプリケーション−インデクスグループの対応付け変更を利用して、第１のユーザアプリケーション１０００と対応付けられているインデクスグループが、第１のインデクスグループ１３００から第２のインデクスグループ１４００に変更することで性能改善を行うことが可能となる。
【０１４５】
さらに、インデクス定義情報をファイルなどにエクスポートすることで、開発に利用しているデータベース管理システムから、実際にサービスを提供する、本番に利用しているデータベース管理システムにインデクスグループの移行を行うこと、又は、実際にサービスを提供する、本番に利用しているデータベース管理システムから、開発に利用しているデータベース管理システムにインデクスグループを移行を行うことが可能となる。
【０１４６】
＜アクセスパス実行ステップ＞
アクセスパス実行ステップでは、プロセッサ３４１０が、アクセスパス実行部３４３５を実行することにより、上述のようなインデクスグループ作成ステップなどにおいて生成されたアクセスパスを実行することで、上記端末３２００などからのＤＢアクセス要求に応じて表３５５０のデータを検索、変更、更新、登録又は削除などの操作を行う。
【０１４７】
（４）本実施の形態の効果など
以上説明したように、上記実施の形態においては、プロセッサ３４１０が、複数のインデクス１５００をグループ化することによりインデクスグループ１３００を作成するインデクスグループ作成ステップと、プロセッサ３４１０が、インデクスグループ１３００の指定されたアクセス要求を受け付け、そのインデクスグループ１３００に含まれるインデクスの中から問い合わせ結果を求める際の性能が最も良いと考えられるインデクスを選択し、そのインデクスを利用してアクセスパスを生成するアクセスパス作成ステップとを実行している。
【０１４８】
上記実施の形態においては、データベース管理装置１２００は、複数のインデクスをグループ化することによりインデクスグループ１３００を作成するインデクスグループ管理部としてのディクショナリ管理部３４３３と、そのインデクスグループ１３００の指定されたアクセス要求を受け付け、そのインデクスグループ１３００に含まれるインデクスの中から問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択し、そのインデクスを利用してアクセスパスを生成するアクセスパス作成部とを有する。このアクセスパス作成部は、上記実施の形態におけるＤＢアクセス要求受付部３４３２、ディスクショナリ管理部３４３３及びアクセスパス生成部３４３４を含んでいる。
【０１４９】
このようにすると、あるユーザアプリケーション（例えば第１のユーザアプリケーション１０００）からのインデクスの追加、変更又は削除といった操作がアクセスパスに対する影響の範囲を限定することができるため、他のアプリケーション（例えば第２のユーザアプリケーション１１００）のアクセスパスに影響を与えないようにすることができる。このため、第２のユーザアプリケーション１１００によるアクセス要求に対応するアクセスパスに影響を与えることなく、ユーザアプリケーションごとに問い合わせ結果を求める際の性能が最も良いアクセスパスを生成するためのインデクスを自由に追加、変更又は削除することができる。
【０１５０】
本実施の形態においては、プロセッサ３４１０が、その生成されたアクセスパスを実行することで上記アクセス要求に応じて前記表のデータを操作する。
【０１５１】
このようにすると、新たな第２のユーザアプリケーション１１００が追加された場合にも、第１のユーザアプリケーション１０００の開発者が意図したとおり、即ち、特定のインデクスグループ１３００に所属するインデクスのみを利用したアクセスパスを実行することで、インデクスの操作追加、変更又は削除に伴って、他方のアクセスパスに影響を与えず、実行性能が変化しないようにすることができる。
【０１５２】
本実施の形態においては、プロセッサ３４１０が、インデクス自体をグループ化する代わりに、インデクスの定義情報をグループ化している。当該定義情報は、本実施の形態におけるインデクス定義情報１５００に相当する。
【０１５３】
本実施の形態においては、プロセッサ３４１０が、インデクスグループ１３００に所属するインデクスを利用して生成されたアクセスパスとともに前記インデクスグループ１３００を含めて表示装置（図示せず）に表示している。
【０１５４】
本実施の形態においては、プロセッサ３４１０が、インデクスグループ１３００に所属するインデクス１８００を変更しようとした場合、そのインデクス１８００が単一のインデクスグループ１３００に所属しているときにはインデクス１８００自体を直接変更する一方、そのインデクス１８００が複数のインデクスグループ１３００，１４００に所属しているときには、インデクス１８００を複製して同一名称を用いた新規な別のインデクス１９００を作成し、さらに複数のインデクスグループ１３００，１４００のうち、別のインデクスが所属すべきインデクスグループ１３００と当該別のインデクスとの対応関係を変更する。
【０１５５】
このようにすると、あるインデクスが複数のインデクスグループ１３００，１４００に所属する場合であっても、そのインデクスの変更が、他のインデクスグループ１４００を利用している第２のユーザアプリケーション１１００のアクセスパスに影響を与えないようにすることができる。
【０１５６】
本実施の形態においては、プロセッサ３４１０が、インデクスグループ１３００に所属するインデクスを削除しようとした場合、削除対象のインデクスが単一のインデクスグループ１３００に所属しているときにはそのインデクスを直接削除し、削除対象のインデクスが複数のインデクスグループ１３００，１４００に所属しているときには、インデクス自体を削除する代わりに、インデクスグループ１３００とインデクスの対応関係を削除する。
【０１５７】
このようにすると、あるインデクスが複数のインデクスグループ１３００に所属する場合であっても、そのインデクスの削除が、他のインデクスグループ１４００を利用している第２のユーザアプリケーション１１００のアクセスパスに影響を与えないようにすることができる。
【０１５８】
本実施の形態においては、上記インデクスグループ作成ステップでは、プロセッサ３４１０が、インデクスグループ１３００を定義するためのインデクスグループ定義要求を受け付けてインデクスグループ１３００を作成する一方、そのインデクスグループ１３００に対してインデクスを定義するためのインデクス定義要求を受け付けてインデクスグループ１３００にインデクスを定義している。
【０１５９】
本実施の形態においては、プロセッサ３４１０が、インデクスグループ１３００などとインデクスとの対応関係を定義する対応関係定義ステップを実行している。本実施の形態においては、当該対応関係の定義は、インデクス−インデクスグループ対応表３５４０又は環境定義ファイル３５１０によって管理されている。
【０１６０】
このようにすると、ユーザアプリケーションのアクセスパスを変更するために、あるインデクスグループ１３００に所属しているインデクスの追加、削除又は変更を繰り返すことなく、所属すべきインデクスグループ１３００を変更するだけで、そのようなインデクスの追加などを行わずにアクセスパスを変更することができる。
【０１６１】
本実施の形態においては、プロセッサ３４１０が、インデクスグループ１３００を複製するとともに、当該インデクスグループ１３００に所属しているインデクスとの対応関係も複製している。
【０１６２】
このようにすると、ユーザアプリケーションのアクセスパスを複製して、性能改善の試行などを行うことができる。
【０１６３】
また、本実施の形態においては、上記データベース管理装置１２００が、上記インデクスグループ管理部として、複数のインデクスをグループ化することによりインデクスグループ１３００を定義する一方、このインデクスグループ１３００に所属させるべきインデクスを定義するディスクショナリ管理部３４３３を備えている。また、データベース管理装置１２００は、上記アクセスパス作成部として、そのアクセス要求を受け付けるＤＢアクセス要求受付部３４３２と、当該ＤＢアクセス要求受付部３４３２によって受け付けられたアクセス要求に基づいて、上記インデクスグループ１３００に含まれるインデクスの中から問い合わせ結果を求める際の性能が最も良いと判断したインデクスを選択するインデクス選択部としてのディクショナリ管理部３４３３と、当該ディクショナリ管理部３４３３によって選択された問い合わせ結果を求める際の性能が最も良いと判断したインデクスを利用してアクセスパスを生成するアクセスパス生成部３４３４を有する。
【０１６４】
（５）その他の実施形態
上記実施形態は、本発明を説明するための例示であり、本発明をこれらの実施形態にのみ限定する趣旨ではない。本発明は、その趣旨を逸脱しない限り、様々な形態で実施することができる。例えば、上記実施形態では、各種プログラムの処理をシーケンシャルに説明したが、特にこれにこだわるものではない。従って、処理結果に矛盾が生じない限り、処理の順序を入れ替え又は並行動作するように構成しても良い。
【図１】
2011107814.tif 000003
【図２】
2011107814.tif 000004
【図３】
2011107814.tif 000005
【図４】
2011107814.tif 000006
【図５】
2011107814.tif 000007
【図６】
2011107814.tif 000008
【図７】
2011107814.tif 000009
【図８】
2011107814.tif 000010
【図９】
2011107814.tif 000011
【図１０】
2011107814.tif 000012
【図１１】
2011107814.tif 000013
【図１２】
2011107814.tif 000014
【図１３】
2011107814.tif 000015
【図１４】
2011107814.tif 000016
【図１５】
2011107814.tif 000017
【図１６】
2011107814.tif 000018
【図１７】
2011107814.tif 000019
【図１８】
2011107814.tif 000020