データベース管理方法、データベース管理装置およびプログラム
【課題】構造化データの検索時間を短縮することができるデータベース管理方法、データベース管理装置及びプログラムを提供する。
【解決手段】構造化データを記憶した補助記憶部４０と、構造化データの管理を行うデータベース管理部１００とを備えたデータベース管理装置１が、構造化データを処理するためのＳＱＬ文から、処理対象となる構造化データの格納位置を示すパスの全てを抽出し、パスが複数抽出された場合に、それぞれのパスを比較して共通部分を共通パスとして抽出し、その共通パスが示す格納位置以降の構造化データについてＳＱＬによる処理を行う。
【解決手段】構造化データを記憶した補助記憶部４０と、構造化データの管理を行うデータベース管理部１００とを備えたデータベース管理装置１が、構造化データを処理するためのＳＱＬ文から、処理対象となる構造化データの格納位置を示すパスの全てを抽出し、パスが複数抽出された場合に、それぞれのパスを比較して共通部分を共通パスとして抽出し、その共通パスが示す格納位置以降の構造化データについてＳＱＬによる処理を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理技術に関する。
【背景技術】
【０００２】
現在、企業間の電子商取引や電子申請システム、電子カルテシステムなどで、様々な情報を共有する手段の１つとして、利便性、拡張性に特徴があるＸＭＬ（eXtensible Markup Language）データをデータベースに格納する機会が増えてきている。また、そのＸＭＬにおいて、Ｗ３Ｃ（World Wide Web Consortium）勧告で公開されたＸＰａｔｈは、ＸＭＬデータの特定部分を指し示すパス言語であり、ＸＭＬデータに対する問い合わせ等において重要な役割を果たしている。
【０００３】
このＸＰａｔｈを処理するには、ルートノードから順に木構造のノードを辿って行う。従って、木構造を辿る処理では、インデクス等でノードを特定できる場合を除き、全ノードを順に辿るため、ＸＰａｔｈおよび木構造の指定によっては、検索に非常に時間がかかってしまう。
【０００４】
また、データベース管理システム（ＤＢＭＳ：DataBase Management System）にＸＭＬデータをそのまま列データとして格納し、従来資産のＲＤＢＭＳ（Relational ＤＢＭＳ）を活用する動きも広まってきている。そして、このＲＤＢＭＳのＸＭＬ列を検索する際には、ＳＱＬ／ＸＭＬを用いる技術がある（例えば、非特許文献１参照）。
【０００５】
従来のＲＤＢＭＳの検索の仕組みでは、まず、入力されるＳＱＬ文を、選択式、表式および探索条件に分解する。そして、表式に示された表にアクセスして構造化データの表を指定し、探索条件でこの構造化データに所定の要素が含まれているか否かを判断し、所定の要素が含まれている構造化データについて選択式に指定された処理を実行し、得られた結果を検索を要求したアプリケーションに返却する。
【非特許文献１】Jim Melton and Stephen Buxton, “Querying XML-XQuery, XPath, and SQL/XML in Context”，Morgan Kaufmann Pablishers，523-582，2006
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、同じＸＭＬデータに対してＸＰａｔｈをＳＱＬ文中に複数指定している場合、複数のＸＰａｔｈの中に関連性をもつものが含まれることが多い。例えば、探索条件のＸＰａｔｈで表式中の特定行のデータを絞り込み、絞り込んだデータの中から選択式のＸＰａｔｈで特定の一部分を射影する場合などにおいては、探索条件のＸＰａｔｈ、表式のＸＰａｔｈ、および選択式のＸＰａｔｈには関連性がある。
【０００７】
従来のＲＤＢＭＳの技術では、選択式、表式および探索条件に関連性のあるＸＰａｔｈが存在する場合でも、選択式、表式および探索条件のそれぞれの処理が別ステップで行われるため、共通のＸＰａｔｈを複数回評価しなければならない。そのため、ＸＰａｔｈが複雑で評価に時間がかかるほど、検索に時間がかかってしまう。
【０００８】
このような背景に鑑みて本発明がなされたのであり、本発明は、構造化データの検索時間を短縮することができるデータベース管理方法、データベース管理装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するため、本発明のデータベース管理方法、データベース管理装置およびプログラムは、構造化データを処理するためのＳＱＬ文から、処理対象となるデータの格納位置を示すパスの全てを抽出し、パスが複数抽出された場合に、それぞれのパスを比較して共通部分を共通パスとして抽出し、その共通パスが示す格納位置以降のデータについてＳＱＬ文に基づく処理を行うことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ルートノードから共通パスに示されるノードまで辿る処理を排除し、構造化データの検索時間を短縮することができるデータベース管理方法、データベース管理装置およびプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１１】
次に、本発明を実施するための最良の形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
【００１２】
なお、本発明において、構造化データは、ＸＭＬデータ、ＳＧＭＬ（Standard Generalized Markup Language）データ等を含むが、本実施形態においては、ＸＭＬデータを例として説明する。
【００１３】
図１は、本実施形態に係るデータベース管理システムの構成例を示す機能ブロック図である。図１に示すように、データベース管理システム７は、情報処理装置５と、ネットワーク６を介して情報処理装置５に通信可能に接続されているデータベース管理装置１とを含んで構成される。
【００１４】
ここで、情報処理装置５は、メインメモリ５０と、ＣＰＵ（Central Processing Unit）５１と、通信部５２とを含んで構成される。メインメモリ５０上にはアプリケーションプログラムを制御するアプリケーション処理部５５がプログラムとして読み込まれ、ＣＰＵ５１を介して処理が実行される。このアプリケーション処理部５５が、データベース管理装置１にＸＭＬデータの問い合わせを行うと、通信部５２を介してネットワーク６経由で問い合わせ要求がデータベース管理装置１へ送られる。
【００１５】
データベース管理装置１は、メインメモリ１０と、ＣＰＵ２０と、通信部３０と、補助記憶部４０とを含んで構成される。
【００１６】
ＣＰＵ２０は、データベース管理装置１の全体の制御および演算を行う。また、通信部３０は、ネットワーク６を介して情報処理装置５から、ＳＱＬ文等のデータを受信する。
【００１７】
補助記憶部４０は、フラッシュメモリ、ハードディスク等の記憶手段からなり、後記するＸＭＬデータ７００、ＸＭＬスキーマ３００、インデクス構成情報４００等を記憶する。
【００１８】
メインメモリ１０はＲＡＭ（Random Access Memory）等の一次記憶装置からなり、メインメモリ１０上にはデータベース管理部１００がプログラムとして読み込まれている。また、メインメモリ１０は、データベース管理部１００が処理する、共通ＸＰａｔｈ２５０、データ格納位置情報６００等（詳細は後記する）を一時的に保存する。
【００１９】
データベース管理部１００は、記憶部４０に記憶されたＸＭＬデータ７００の処理に関する制御を行い、ＳＱＬ解析部１１０と、定義情報解析部１２０と、ＳＱＬ最適化部１３０と、ＳＱＬ実行部１４０と、制御部１５０とを含んで構成される。なお、このデータベース管理部１００は、例えばデータベース管理装置１の補助記憶部４０に記憶されたプログラムを、ＣＰＵ２０がメインメモリ１０に展開し実行することで実現される。
【００２０】
ＳＱＬ解析部１１０は、通信部３０を介して情報処理装置５のアプリケーション処理部５５から取得したＳＱＬ文を解析する。このＳＱＬ解析部１１０は、ＳＱＬ分解部１１１と、ヒント情報解析部１１２とを含んで構成される。
【００２１】
ＳＱＬ分解部１１１は、取得したＳＱＬ文を、選択式、表式および探索条件に分解する。なお、ＸＭＬデータ７００の検索処理に用いられるＳＱＬ文には、ＸＭＬデータ７００の表を指定する表式およびＸＭＬデータ７００を所定の要素の中から射影する選択式を少なくとも含み、さらに対象となるＸＭＬデータ７００の中から特定の行を取り出す探索条件を含むことができる。
【００２２】
図２は、図１の情報処理装置のアプリケーション処理部からネットワークを介してＳＱＬ解析部が取得する、ＳＱＬ文の一例を示す図である。図２に示すように、ＳＱＬ文２００は、ＳＥＬＥＣＴ句で指定される選択式２０１と、ＦＲＯＭ句で指定される表式２０２と、ＷＨＥＲＥ句で指定される探索条件２０３とを含んでいる。また、ＳＱＬ文２００は、選択式２０１、表式２０２および探索条件２０３の他に、後記するヒント情報を含むことができる。なお、このヒント情報は、共通ＸＰａｔｈ２５０を使用してＳＱＬ文の処理を行うか否かを指定する情報であり、詳細は後記する（図８参照）。
【００２３】
図１に戻り、ヒント情報解析部１１２は、後記する共通ＸＰａｔｈ２５０を用いて処理を行うか否かを指定するヒント情報がＳＱＬ文に含まれているか否かを解析し、ヒント情報が含まれている場合には、その指示に従い、共通ＸＰａｔｈ２５０を用いてＸＭＬデータ７００の処理を行うか否かを判断する。
【００２４】
次に、定義情報解析部１２０は、ＳＱＬ分解部１１１で分解されたＳＱＬ文から、処理対象となるデータの格納位置を指定するＸＰａｔｈを示す文字列を切り出す。そして、定義情報解析部１２０は、後記するＸＭＬスキーマ３００またはインデクス構成情報４００に基づき、ルートノードから処理対象となるデータの格納位置までの最短経路のＸＰａｔｈを取得する。本例では、最短経路を例にしているが、必ずしも最短経路に限定されるものではなく、より短い経路の方が効果は高くなるが、経路を記憶して利用することで検索実行時間は短縮される。この定義情報解析部１２０は、ＸＭＬスキーマ解析部１２１と、インデクス構成情報解析部１２２とを含んで構成される。
【００２５】
ＸＭＬスキーマ解析部１２１は、ＳＱＬ文からＸＰａｔｈを示す文字列を切り出し、切り出したＸＰａｔｈを示す文字列それぞれが、省略記法で指定されている場合には、フルパス記法に変換し、逆文書順の記法で指定されている場合には、文書順の記法に変換する。そして、ＸＭＬスキーマ解析部１２１は、変換したＸＰａｔｈを示す文字列と、補助記憶部４０に記憶されたＸＭＬスキーマ３００とを、ルートノードからＸＰａｔｈで指定されるノードまで順に突き合せ、選択式から取得した最短経路のＸＰａｔｈ２１０、表式から取得した最短経路のＸＰａｔｈ２２０および探索条件から取得した最短経路のＸＰａｔｈ２３０を取得し、メインメモリ１０上に保持する。
【００２６】
図３は、図１の補助記憶部に記憶されるＸＭＬスキーマの一例を示す図である。図３（ａ）に示すように、ＸＭＬスキーマ３００によりＸＭＬ文書の構造が定義される。例えば、符号３０１に示す定義文は、ルートノードの要素が「book_info」であることを宣言し、符号３０２に示す定義文は、子要素として「title」「price」「author」「contents」があることを宣言する。また、「contents」の要素をさらにref属性で宣言し、その参照先として符号３０３に示す定義文が記述され、「contents」の子要素として、「foreword」「chapter」があることを宣言する。そして、さらに「chapter」の子要素として、符号３０４に示す定義文が記述され「introduction」「section」「summery」があることを宣言する。
【００２７】
図３（ｂ）は、図３（ａ）のＸＭＬスキーマで定義された内容を木構造として表現した図である。ＸＭＬスキーマ３００をメインメモリ１０上に展開すると、ルートノードからＸＰａｔｈで指定されているノードまでを探索することができる。従って、ＸＭＬスキーマ解析部１２１は、選択式、表式および探索条件に含まれるＸＰａｔｈを示す文字列とＸＭＬスキーマ３００とを、ルートノードからＸＰａｔｈで指定されるノードまで文書順に突き合せ、最短経路のＸＰａｔｈを特定することができる。
【００２８】
図１に戻り、インデクス構成情報解析部１２２は、ＳＱＬ文からＸＰａｔｈを示す文字列を切り出し、切り出されたＸＰａｔｈを示す文字列それぞれが、省略記法で指定されている場合には、フルパス記法に変換し、逆文書順の記法で指定されている場合には、文書順の記法に変換する。そして、インデクス構成情報解析部１２２は、変換したＸＰａｔｈを示す文字列と、補助記憶部４０に記憶されたインデクス構成情報４００とを、ルートノードからＸＰａｔｈで指定されるノードまで順に突き合せ、選択式から取得した最短経路のＸＰａｔｈ２１０、表式から取得した最短経路のＸＰａｔｈ２２０および探索条件から取得した最短経路のＸＰａｔｈ２３０を取得し、メインメモリ１０上に保持する。
【００２９】
図４は、図１の補助記憶部に記憶されるインデクス構成情報の一例を示す図である。図４（ａ）は、本実施形態に係るインデクス構成情報の一例を示す図である。図４（ｂ）は、図４（ａ）に示したインデクス構成情報の一例を木構造で表現した図である。図４（ａ）に示すように、インデクス定義が指定されると、データベース管理部１００は、インデクス定義４１０からインデクス管理情報４２０を生成する。このインデクス管理情報４２０は、インデクス名（INDX_NAME）、表名（TBL_NAME）、列名（COL_NAME）、データ型（DATA_TYPE）と共に、インデクス定義時に指定したキーを特定するＸＰａｔｈ（以下、インデクス構成情報４００という）を含み、補助記憶部４０に記憶される。
【００３０】
図４（ｂ）は、例えば、インデクス構成情報４００が‘/book_info/contents’の場合に、インデクスキーを特定するＸＰａｔｈの内容を木構造で表現した図である。インデクス構成情報４００を図１のメインメモリ１０上に展開すると、ルートノードからＸＰａｔｈで指定されるノードまで探索することができる。従って、ＸＭＬスキーマ３００が補助記憶部４０に記憶されていない場合においても、インデクス構成情報解析部１２２は、選択式、表式および探索条件のＸＰａｔｈを示す文字列とインデクス構成情報４００で定義される木構造とを、ルートノードからＸＰａｔｈで指定されるノードまで文書順に突き合せ、最短経路のＸＰａｔｈを特定することができる。
【００３１】
図１に戻り、ＳＱＬ最適化部１３０は、定義情報解析部１２０で抽出された選択式、表式および探索条件それぞれの最短経路のＸＰａｔｈを示す文字列から、共通部分を共通ＸＰａｔｈ２５０として抽出し、抽出した共通ＸＰａｔｈ２５０を用いて、アクセスプランを決定する。このＳＱＬ最適化部１３０は、共通ＸＰａｔｈ抽出部１３１とアクセスプラン決定部１３２とを含んで構成される。
【００３２】
共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した探索条件から取得した最短経路のＸＰａｔｈ２３０、選択式から取得した最短経路のＸＰａｔｈ２１０および表式から取得した最短経路のＸＰａｔｈ２２０を読み出し、ＸＰａｔｈを下位のノードからルートノードに向かって突き合せる。なお、このとき、ＸＰａｔｈをルートノードから順に突き合せるようにしてもよい。共通ＸＰａｔｈ抽出部１３１は、突き合せた結果、一致したＸＰａｔｈを共通ＸＰａｔｈ２５０としてメインメモリ１０上に保持する。
【００３３】
アクセスプラン決定部１３２は、共通ＸＰａｔｈ抽出部１３１が抽出した共通ＸＰａｔｈ２５０を用いて、アクセスコストが最小となるものをアクセスプランとして決定する。なお、本実施形態におけるアクセスプラン（「クエリプラン」ともいう）とは、表式の評価、探索条件の評価、行ＩＤ返却、共通ＸＰａｔｈ２５０が示すデータ格納位置情報返却、行ＩＤに基づきデータ取得、データ格納位置情報６００に基づき共通ＸＰａｔｈ２５０が示すノード以下のデータ取得、そして選択式のＸＰａｔｈ評価を行う手順をいう。また、本実施形態において、表式の評価とは、ＳＱＬ文中の表式に基づいて、構造化データの表にアクセスすることをいう。また、探索条件の評価とは、探索条件に示される所定の要素が条件を満たすか否かの「真」「偽」を判断することをいう。そして、選択式のＸＰａｔｈ評価とは、メインメモリ上に展開されている構造化データから、選択式に示される所定の要素が含まれているか否かを判断することをいう。
【００３４】
図５は、本実施形態における各処理のアクセスコストを示すアクセスコスト設定情報の一例を示す図である。図５に示すように、このアクセスコスト設定情報５００で示される各アクセスコストは、例えば当該処理内容の実行に要する処理時間に応じた相対値で予め設定しておくものである。例えば、表式のＸＰａｔｈ評価およびルートノード以降の探索条件のＸＰａｔｈ評価に要するアクセスコストは、補助記憶部４０にアクセスし条件評価を行うため、「２０００」と比較的大きい値が設定される。一方、探索条件のＸＰａｔｈ評価に要するアクセスコストおよび選択式のＸＰａｔｈ評価のアクセスコストは、共通ＸＰａｔｈ２５０が示すノード以降を評価する場合は、ルートノード以降を評価する場合に比べて、小さく設定される。これは、共通ＸＰａｔｈ２５０を使用することにより、評価を省略することができるノード数に応じて、アクセスコストが低減できる可能性があるからである。また、選択式のＸＰａｔｈ評価のアクセスコストは、メインメモリ１０上に格納されているデータを用いて行うため、表式のＸＰａｔｈ評価および探索条件のＸＰａｔｈ評価のアクセスコストに比べて小さく設定される。行ＩＤ返却および共通ＸＰａｔｈ２５０が示すノードのデータ格納位置情報返却に要するアクセスコストは、行ＩＤからのデータ取得に比べてデータ長が短いため、極めて小さい値となる。位置情報から共通ＸＰａｔｈ２５０が示すノードのデータ取得では、メインメモリ１０上に格納されたデータを用いるため、アクセスコストを小さく設定している。アクセスコストは、このようにそれぞれに設定されたアクセスコストを合算して求められ、共通ＸＰａｔｈ２５０の組合わせのうち、アクセスコストが最小となるものに、アクセスプランを決定する。
【００３５】
図１に戻り、ＳＱＬ実行部１４０は、アクセスプラン決定部１３２で決定したアクセスプランに基づいて、ＳＱＬを実行するものであり、データベースアクセス部１４１と、探索条件評価部１４２と、選択式実行部１４３とを含んで構成される。
【００３６】
データベースアクセス部１４１は、補助記憶部４０に記憶されているＸＭＬデータ７００のうち操作の対象となる表を指定する（例えば図２の表式２０２で指定される‘ＢＯＯＫ＿ＴＢＬ’）。また、探索条件評価部１４２は、表で示されるデータの探索条件の評価を行い、探索条件の評価が真となった行の行ＩＤおよび共通ＸＰａｔｈ２５０が示すノードの位置情報を取得し、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００（詳細は後記する図６参照）をメインメモリ１０上に保持する処理を行う。
【００３７】
選択式実行部１４３は、データ格納位置情報６００に格納されている行ＩＤからデータを取得し、メインメモリ１０上にデータを保持する。そして、選択式実行部１４３は、データ格納位置情報６００に格納されている位置情報を用いて、メインメモリ１０上に展開されているデータから、共通ＸＰａｔｈ２５０が示すノード以降のデータを取得する処理を行う。そして、ルートノードから、共通ＸＰａｔｈ２５０で示されるノードまでの評価を行わず、選択式のＸＰａｔｈを共通ＸＰａｔｈ２５０で示すノード以降のデータに対して評価を行う。
【００３８】
図６は、本実施形態におけるデータ格納位置情報の例を示す図である。図６（ａ）は、列情報、行ＩＤおよび位置情報がデータ格納位置情報として含まれる例を示す。図６（ｂ）は、さらに子孫ノード情報とノードテスト情報とがデータ格納位置情報として含まれる例を示す。図６（ａ）に示すように、データ格納位置情報６００は、共通ＸＰａｔｈ２５０が指定されている列を特定するための列情報６１０と、探索条件の評価が真になった行を特定するための行ＩＤ６２０と、共通ＸＰａｔｈ２５０が示すデータの位置情報６３０とを有する。また、表式のＸＰａｔｈ評価時に取得する場合のデータ格納位置情報６００も同様に、共通ＸＰａｔｈ２５０が指定されている列を特定するための列情報６１０と、探索条件が真になった行を特定するための行ＩＤ６２０と、共通ＸＰａｔｈ２５０が示すデータの位置情報６３０とを有する。
【００３９】
また、図６（ｂ）に示すように、このデータ格納位置情報６００は、列情報６１０、行ＩＤ６２０、データの位置情報６３０に加えて、共通ＸＰａｔｈ２５０の示すノードの子孫ノードの有無を識別する情報である子孫ノード情報６４０およびノードテストに合致したか否かを示す情報であるノードテスト情報６５０を含むことができる。
【００４０】
この子孫ノード情報６４０を用いることで、探索条件評価部１４２および選択式実行部１４３は、共通ＸＰａｔｈ２５０が示すノードに子孫ノードが存在する場合のみ、ＸＰａｔｈの評価を行う。従って、子孫ノードが存在しないと判断できる場合は、探索条件評価部１４２および選択式実行部１４３は、ＸＰａｔｈ評価を行わない。すなわち、探索条件評価部１４２は、条件判定を偽とする処理を行い、選択式実行部１４３はＮＵＬＬを返却する処理を行う。
【００４１】
また、共通ＸＰａｔｈ２５０の示すノードがノードテストに合致したか否かを示すノードテスト情報６５０を用いることにより、ノードテストに合致した場合にのみ探索条件評価部１４２および選択式実行部１４３はＸＰａｔｈの評価を行う。ノードテストに合致しない場合は、探索条件評価部は、条件判定を偽とする処理を行い、選択式実行部１４３は、ＮＵＬＬを返却する処理を行う。
【００４２】
次に、図１を参照しつつ、図７に沿って、本実施形態に係るデータベース管理方法の処理を説明する。図７は、入力されたＳＱＬ文からアクセスコストが最小となるアクセスプランを作成するまでの例を示している。なお、図７においては、図２に示すＳＱＬ文２００がデータベース管理装置１に入力されたものとして説明する。
【００４３】
まず、情報処理装置５（図１参照）のアプリケーション処理部５５を介してネットワーク６経由で、データベース管理装置１にＳＱＬ文２００が入力される（ステップＳ７０１）。ＳＱＬ文２００が入力されると、まず、ヒント情報解析部１１２の処理により、ＳＱＬ文２００の中に「共通ＸＰａｔｈ使用不可」のヒント情報が含まれているか否かを判断する（ステップＳ７０２）。そして、ＳＱＬ文２００の中に「共通ＸＰａｔｈ使用不可」のヒント情報は含まれていなければ（ステップＳ７０２→Ｎｏ）、ステップＳ７０３へ進む。一方、ＳＱＬ文の中に「共通ＸＰａｔｈ使用不可」のヒント情報が含まれていれば（ステップＳ７０２→Ｙｅｓ）、ステップＳ７０７へ進み、アクセスプランを決定処理を行う。
【００４４】
図８は、共通ＸＰａｔｈの使用の可否を指定するヒント情報が含まれているＳＱＬ文の例を示す図である。図８（ａ）は、共通ＸＰａｔｈを使用することを指示するヒント情報を含む例である。また、図８（ｂ）は、共通ＸＰａｔｈを使用しないこと指示するヒント情報を含む例である。
【００４５】
図８（ａ）に示すＳＱＬ文の中には、ヒント情報８００として、「ＷＩＴＨ ＸＰＡＴＨ句」が指定されている。この「ＷＩＴＨ ＸＰＡＴＨ句」は、このヒント情報８００で予め指定した共通ＸＰａｔｈ２５０を使用してアクセスプランを作成することを指示するものである。図８（ａ）の例においては、‘book_info/contents/chapter1’が共通ＸＰａｔｈ２５０として指定される。このようにヒント情報８００で共通ＸＰａｔｈ２５０を使用することが指示されると、アクセスプラン決定部１３２は、アクセスコストが最小でなくても、指定された共通ＸＰａｔｈ２５０を用いてアクセスプランを決定する。
【００４６】
このようにすることで、予め共通ＸＰａｔｈ２５０が分かっている場合に、ＳＱＬ実行部１４０（図１参照）は、ヒント情報８００で指定した共通ＸＰａｔｈ２５０を用いてＸＭＬデータ７００の検索をすることが可能となる。
【００４７】
また、図８（ｂ）に示すＳＱＬ文の中には、ヒント情報８００として、「ＷＩＴＨＯＵＴ ＸＰＡＴＨ句」が指定されている。この「ＷＩＴＨＯＵＴ ＷＰＡＴＨ句」は、共通ＸＰａｔｈ２５０を使用しないことを指示するものである。このヒント情報８００の指示により、アクセスプラン決定部１３２は、アクセスコストが最小でなくても、共通ＸＰａｔｈ２５０を使用しないアクセスプランを決定する。
【００４８】
なお、図８に示すヒント情報８００である「ＷＩＴＨ ＸＰＡＴＨ句」および「ＷＩＴＨＯＵＴ ＸＰＡＴＨ句」は、共通ＸＰａｔｈ２５０の使用可否を指定する一例であり、その他の記法で使用可否を指定することも可能である。
また、図８に示すヒント情報８００は、ＳＱＬ文単位で共通ＸＰａｔｈ２５０の使用可否をユーザが指定できるものであるが、例えば、情報処理装置５のアプリケーション処理部５５から、アプリケーション単位またはデータベース管理システム単位のヒント情報をデータベース管理部１００が取得し、ＸＭＬデータ７００の問い合わせが行なわれる際に、ヒント情報解析部１１２が、そのヒント情報に従い共通ＸＰａｔｈ２５０を用いて処理を行うか否かを判断することもできる。ここで、アプリケーション単位のヒント情報およびデータベース単位のヒント情報は、データベース管理部１００内のヒント情報解析部１１２において、共通ＸＰａｔｈ２５０の使用可否の設定を行うことができる。そして、この設定によりアクセスプラン決定部１３２は、アクセスコストが最小でなくても、共通ＸＰａｔｈ２５０を用いてアクセスプランを決定することができ、また、アクセスコストが最小でなくても、共通ＸＰａｔｈ２５０を使用しないアクセスプランを決定することができる。
【００４９】
このようにすることで、共通ＸＰａｔｈ２５０を使う必要がない場合や、共通ＸＰａｔｈ２５０を用いても、アクセスコストが低減しないことが明らかな場合において、ユーザはヒント情報８００を用いて、共通ＸＰａｔｈ２５０を使用しない処理を設定することができる。
【００５０】
図７に戻り、ステップＳ７０２において、ＳＱＬ文２００中に「共通ＸＰａｔｈ使用不可」のヒント情報８００が含まれていなかった場合（ステップＳ７０２→Ｎｏ）、ＳＱＬ分解部１１１は、入力されたＳＱＬ文２００を、選択式２０１、表式２０２、探索条件２０３に分解する（ステップＳ７０３）。「共通ＸＰａｔｈ使用」のヒント情報８００が含まれる場合、またはヒント情報自体がない場合もステップＳ７０２→Ｎｏの処理を行う。
【００５１】
次に、ＸＭＬスキーマ解析部１２１は、ＳＱＬ分解部１１１が分解した、選択式２０１、表式２０２、探索条件２０３から、処理対象となるデータの格納位置を指定するＸＰａｔｈを示す文字列を切り出す（ステップＳ７０４）。続いて、ＸＭＬスキーマ解析部１２１は、ステップＳ７０４で切り出した文字列により示されるＸＰａｔｈから、最短経路を示すＸＰａｔｈを取得する処理を行う（ステップＳ７０５）（詳細は後記する図１１〜図１２参照）。ＸＭＬスキーマ解析部１２１は、切り出した文字列が省略記法で指定されている場合には、フルパス記法に変換し、逆文書順の記法で指定されている場合には、文書順の記法に変換した上で、それぞれの文字列を補助記憶部４０に記憶されたＸＭＬスキーマ３００と突き合せる。ＸＭＬスキーマ解析部１２１は、突き合せた結果一致したＸＰａｔｈを、選択式から取得した最短経路のＸＰａｔｈ２１０、表式から取得した最短経路のＸＰａｔｈ２２０、探索条件から取得した最短経路のＸＰａｔｈ２３０としてメインメモリ１０上に保持する。なお、図７において入力されたＳＱＬ文２００（図２参照）の例においては、表式２０２にＸＰａｔｈを示す文字列がないため、ＸＭＬスキーマ解析部１２１は、表式２０２からはＸＰａｔｈを示す文字列の切り出しを行わない。
【００５２】
また、ＸＭＬスキーマ３００がない場合は、インデクス構成情報解析部１２２が、補助記憶部４０に記憶されたインデクス構成情報４００を用いて、ＸＰａｔｈの切り出しを行う（詳細は後記する図１３〜図１４参照）。
【００５３】
続いて、共通ＸＰａｔｈ抽出部１３１は、共通ＸＰａｔｈ２５０の抽出処理を行う（ステップＳ７０６）（詳細は後記する図１５参照）。共通ＸＰａｔｈ抽出部１３１は、ＸＭＬスキーマ解析部１２１またはインデクス構成情報解析部１２２の処理により取得した最短経路のＸＰａｔｈそれぞれを下位のノードからルートノードへ向かって突き合せる。そして、共通ＸＰａｔｈ抽出部１３１は、突き合せた結果、一致したＸＰａｔｈを共通ＸＰａｔｈ２５０としてメインメモリ１０上に保持する。図７の例においては、選択式から取得した最短経路のＸＰａｔｈ２１０と、探索条件から取得した最短経路のＸＰａｔｈ２３０とを突き合せ、共通ＸＰａｔｈ２５０として‘book_info/contents/chapter1’が、共通ＸＰａｔｈ抽出部１３１により抽出される。
【００５４】
図９は、図７に示した例において、共通ＸＰａｔｈ抽出部が抽出した共通ＸＰａｔｈを木構造で表現した図である。図９に示すように、共通ＸＰａｔｈ２５０として‘book_info/contents/chapter1’が、ルートノードである「book_info」から「chapter1」までのパスとして、共通ＸＰａｔｈ抽出部１３１により抽出される。
【００５５】
図７に戻り、アクセスプラン決定部１３２は、アクセスプラン決定処理を行う（ステップＳ７０７）（詳細は後記する図１６参照）。ここでアクセスプラン決定部１３２は、抽出した共通ＸＰａｔｈ２５０を使用するアクセスプランと、共通ＸＰａｔｈ２５０を使用しないアクセスプランとを比較し、アクセスコストが最小となるアクセスプランを決定する。
【００５６】
図１０は、共通ＸＰａｔｈを使用してアクセスコストの合計値を算出したアクセスプランと、共通ＸＰａｔｈを使用しないでアクセスコストの合計値を算出したアクセスプランとを、比較した例を示す図である。アクセスプラン決定部１３２は、図５に示したアクセスコスト設定情報５００で設定された各処理ごとのアクセスコストに基づき、共通ＸＰａｔｈ２５０を使用した場合のアクセスコストの合計値と、共通ＸＰａｔｈ２５０を使用しない場合のアクセスコストの合計値とを算出する。図１０に示す例においては、共通ＸＰａｔｈ２５０を使用する場合（プラン１）のアクセスコストの合計値は「３５３０」であり、共通ＸＰａｔｈ２５０を使用しない場合（プラン２）のアクセスコストの合計値は「４０１０」であるため、アクセスプラン決定部１３２は、アクセスコストが最小となる方である共通ＸＰａｔｈ２５０を使用するアクセスプラン（プラン１）に、アクセスプランを決定する。
【００５７】
図７に戻り、アクセスプラン決定部１３２により決定されたアクセスプランに基づき、ＳＱＬ実行部１４０は、アクセスプランの実行処理を行う（ステップＳ７０８）（詳細は後記する図１７〜図２０参照）。
【００５８】
（最短経路を示すＸＰａｔｈ取得処理）
次に、ＸＭＬスキーマ解析部１２１による最短経路を示すＸＰａｔｈの取得処理について詳細に説明する。なお、図７に示すステップにおいては、ステップＳ７０４およびステップＳ７０５の処理に該当する。
【００５９】
図１１および図１２は、図１に示すＸＭＬスキーマ解析部が、切り出された選択式、表式および探索条件それぞれから、最短経路を示すＸＰａｔｈの取得する際の流れを示すフローチャートである。
【００６０】
図１１に示すように、まず、ＸＭＬスキーマ解析部１２１は、補助記憶部４０（図１参照）にＸＭＬスキーマ３００があるか否か判定する（ステップＳ１１０１）。ＸＭＬスキーマ３００があれば（ステップＳ１１０１→Ｙｅｓ）、ＸＭＬスキーマ解析部１２１は、探索条件２０３からＸＰａｔｈを示す文字列を切り出す（ステップＳ１１１０）。次に、ＸＭＬスキーマ解析部１２１は、切り出した文字列が省略記法の場合、フルパスの記法に変換する（ステップＳ１１１１）。続いてＸＭＬスキーマ解析部１２１は、切り出した文字列が逆文書順の記法の場合、文書順の記法に変換する（ステップＳ１１１２）。そしてＸＭＬスキーマ解析部１２１は、変換したＸＰａｔｈとＸＭＬスキーマ３００とをルートノードから文書順に突き合せる（ステップＳ１１１３）。続いてＸＭＬスキーマ解析部１２１は、突き合せで一致したＸＰａｔｈを探索条件から取得した最短経路のＸＰａｔｈ２３０としてメインメモリ１０上に保持する（ステップＳ１１１４）。次に、ＸＭＬスキーマ解析部１２１は、探索条件２０３中のＸＰａｔｈの全てを突き合せたか否かを判断する（ステップＳ１１１５）。まだ突き合せていないＸＰａｔｈがある場合には（ステップＳ１１１５→Ｎｏ）、ステップＳ１１１０に戻り処理を続ける。一方、探索条件２０３中のＸＰａｔｈの全てを突き合せた場合には（ステップＳ１１１５→Ｙｅｓ）、ステップＳ１１１６の処理へ進む。そして、ＸＭＬスキーマ解析部１２１は、探索条件から取得した最短経路のＸＰａｔｈ２３０のうち、重複しているＸＰａｔｈがあれば、メインメモリ１０上から削除する（ステップＳ１１１６）。なお、ステップＳ１１０１において、補助記憶部４０にＸＭＬスキーマ３００がなければ（ステップＳ１１０１→Ｎｏ）、後記する図１３のインデクス構成情報解析部１２２によるステップＳ１３０１へ進む。
【００６１】
次にＸＭＬスキーマ解析部１２１は、選択式２０１からＸＰａｔｈを示す文字列を切り出す（ステップＳ１１２０）。そして、ＸＭＬスキーマ解析部１２１は、選択式２０１から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１１１１〜Ｓ１１１６までの処理と同様の処理（ステップＳ１１２１〜Ｓ１１２６）を行って、突き合せで一致したＸＰａｔｈを選択式から取得した最短経路のＸＰａｔｈ２１０としてメインメモリ１０上に保持する。
【００６２】
続いて、ＸＭＬスキーマ解析部１２１は、図１２のステップＳ１１３０に進み、表式２０２からＸＰａｔｈを示す文字列を切り出す。ＸＭＬスキーマ解析部１２１は、表式２０２から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１１１１〜Ｓ１１１６までの処理と同様の処理（ステップＳ１１３１〜Ｓ１１３６）を行って、突き合せで一致したＸＰａｔｈを表式から取得した最短経路のＸＰａｔｈ２２０としてメインメモリ１０上に保持する。
【００６３】
また、補助記憶部４０にインデクス構成情報４００が記憶されている場合、インデクス構成情報解析部１２２は、インデクス構成情報４００を用いて、最短経路を示すＸＰａｔｈを取得する処理を行う。図１３および図１４は、インデクス構成情報解析部が、切り出された選択式、表式および探索条件それぞれから、最短経路を示すＸＰａｔｈを取得する際の流れを示すフローチャートである。
【００６４】
まず、インデクス構成情報解析部１２２は、補助記憶部４０（図１参照）にインデクス構成情報４００があるか否かを判定する（ステップＳ１３０１）。インデクス構成情報４００があれば（ステップＳ１３０１→Ｙｅｓ）、インデクス構成情報解析部１２２は、探索条件２０３からＸＰａｔｈを示す文字列を切り出す（ステップＳ１３１０）。次に、インデクス構成情報解析部１２２は、切り出した文字列が省略記法の場合、フルパスの記法に変換する（ステップＳ１３１１）。続いてインデクス構成情報解析部１１２は、切り出した文字列が逆文書順の記法の場合、文書順の記法に変換する（ステップＳ１３１２）。そしてインデクス構成情報解析部１２２は、変換したＸＰａｔｈとインデクス構成情報４００とをルートノードから文書順に突き合せる（ステップＳ１３１３）。続いてインデクス構成情報解析部１２２は、突き合せで一致したＸＰａｔｈを探索条件から取得した最短経路のＸＰａｔｈ２３０としてメインメモリ１０上に保持する（ステップＳ１３１４）。次に、インデクス構成情報解析部１２２は、探索条件２０３中のＸＰａｔｈの全てを突き合せたか否かを判断する（ステップＳ１３１５）。まだ突き合せていないＸＰａｔｈがある場合には（ステップＳ１３１５→Ｎｏ）、ステップＳ１３１０に戻り処理を続ける。一方、探索条件２０３中のＸＰａｔｈの全てを突き合せた場合には（ステップＳ１３１５→Ｙｅｓ）、ステップＳ１３１６の処理へ進む。そして、インデクス構成情報解析部１２２は、探索条件から取得した最短経路のＸＰａｔｈ２３０のうち、重複しているＸＰａｔｈがあれば、メインメモリ１０上から削除する（ステップＳ１３１６）。なお、ステップＳ１３０１において、補助記憶部４０にインデクス構成情報４００がなければ（ステップＳ１３０１→Ｎｏ）、処理を終える。
【００６５】
次にインデクス構成情報解析部１２２は、選択式２０１からＸＰａｔｈを示す文字列を切り出す（ステップＳ１３２０）。そして、インデクス構成情報解析部１２２は、選択式２０１から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１３１１〜Ｓ１３１６までの処理と同様の処理（ステップＳ１３２１〜Ｓ１３２６）を行って、突き合せで一致したＸＰａｔｈを選択式から取得した最短経路のＸＰａｔｈ２１０としてメインメモリ１０上に保持する。
【００６６】
続いて、インデクス構成情報解析部１１２は、図１４のステップＳ１３３０に進み、表式２０２からＸＰａｔｈを示す文字列を切り出す。インデクス構成情報解析部１２２は、表式２０２から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１３１１〜Ｓ１３１６までの処理と同様の処理（ステップＳ１３３１〜Ｓ１３３６）を行って、突き合せで一致したＸＰａｔｈを表式から取得した最短経路のＸＰａｔｈ２２０としてメインメモリ１０上に保持する。
【００６７】
（共通ＸＰａｔｈ抽出処理）
次に、図７のステップＳ７０６の処理である、共通ＸＰａｔｈ抽出部１３１が共通ＸＰａｔｈ２５０を抽出する流れを具体的に説明する。図１５は、共通ＸＰａｔｈ抽出部が共通ＸＰａｔｈを抽出する流れを示すフローチャートである。
【００６８】
図１５に示すように、まず、共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した探索条件から取得した最短経路のＸＰａｔｈ２３０があるか否か判定する（ステップＳ１５０１）。共通ＸＰａｔｈ抽出部１３１は、探索条件から取得した最短経路のＸＰａｔｈ２３０があれば（ステップＳ１５０１→Ｙｅｓ）、探索条件から取得した最短経路のＸＰａｔｈ２３０を読み込む（ステップＳ１５０２）。探索条件から取得した最短経路のＸＰａｔｈ２３０がなければ（ステップＳ１５０１→Ｎｏ）、探索条件２０３からＸＰａｔｈを示す文字列を、探索条件から取得した最短経路のＸＰａｔｈ２３０として切り出す（ステップＳ１５０３）。
【００６９】
次に、共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した選択式から取得した最短経路のＸＰａｔｈ２１０があるか否か判定する（ステップＳ１５０４）。選択式から取得した最短経路のＸＰａｔｈ２１０があれば（ステップＳ１５０４→Ｙｅｓ）、共通ＸＰａｔｈ抽出部１３１は、選択式から取得した最短経路のＸＰａｔｈ２１０を読み込む（ステップＳ１５０５）。選択式から取得した最短経路のＸＰａｔｈ２１０がなければ（ステップＳ１５０４→Ｎｏ）、選択式２０１からＸＰａｔｈを示す文字列を、選択式から取得した最短経路のＸＰａｔｈ２１０として切り出す（ステップＳ１５０６）。
【００７０】
続いて、共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した表式から取得した最短経路のＸＰａｔｈ２２０があるか否かを判定する（ステップＳ１５０７）。表式から取得した最短経路のＸＰａｔｈ２２０があれば（ステップＳ１５０７→Ｙｅｓ）、共通ＸＰａｔｈ抽出部１３１は、表式から取得した最短経路のＸＰａｔｈ２２０を読み込む（ステップＳ１５０８）。表式から取得した最短経路のＸＰａｔｈ２２０がなければ（ステップＳ１５０７→Ｎｏ）、表式２０２からＸＰａｔｈを示す文字列を、表式から取得した最短経路のＸＰａｔｈ２２０として切り出す（ステップＳ１５０９）。
【００７１】
なお、共通ＸＰａｔｈ抽出部１３１が行うステップＳ１５０３、ステップＳ１５０６およびステップＳ１５０９における、探索条件２０１、選択式２０２および表式２０３からＸＰａｔｈを示す文字列を切り出す処理は、補助記憶部４０に、ＸＭＬスキーマ３００およびインデクス構成情報４００が記憶されていない場合に行われる処理である。ただし、このステップＳ１５０３、ステップＳ１５０６およびステップＳ１５０９における処理は、共通ＸＰａｔｈ抽出部１３１に予め設定することにより、これらのステップを行わないことも可能である。その場合、例えば、共通ＸＰａｔｈ抽出部１３１は、ステップＳ１５０１において、メインメモリ１０上に保持した探索条件から取得した最短経路のＸＰａｔｈ２１０がなければ（ステップＳ１５０１→Ｎｏ）、探索条件から取得したＸＰａｔｈの読み込みを行わず、次のステップＳ１５０４へ進む。同様に、選択式からＸＰａｔｈを示す文字列を最短経路の文字列として切り出すステップＳ１５０６が設定されていない場合には、次のステップＳ１５０７へ進む。また、表式からＸＰａｔｈを示す文字列を最短経路の文字列として切り出すステップＳ１５０９が設定されていない場合には、次のステップＳ１５１０へ進む。
【００７２】
次に、共通ＸＰａｔｈ抽出部１３１は、読み込んだ探索条件から取得したＸＰａｔｈ２３０、選択式から取得したＸＰａｔｈ２１０および表式から取得したＸＰａｔｈ２２０それぞれを、下位ノードからルートノードへ向かって突き合せる（ステップＳ１５１０）。そして、共通ＸＰａｔｈ抽出部１３１は、一致したＸＰａｔｈを共通ＸＰａｔｈ２５０としてメインメモリ１０上に保持する（ステップＳ１５１１）。続いて共通ＸＰａｔｈ抽出部１３１は、最短経路のＸＰａｔｈの全てを突き合せたか否かを判断する（ステップＳ１５１２）。そして、突き合せていない最短経路のＸＰａｔｈがある場合には（ステップＳ１５１２→Ｎｏ）、ステップＳ１５１０に戻り処理を続ける。一方、全てのＸＰａｔｈの突き合せが終わっている場合には（ステップＳ１５１２→Ｙｅｓ）、ステップＳ１５１３へ進み、抽出した共通ＸＰａｔｈ２５０のうち、重複している共通ＸＰａｔｈ２５０をメインメモリ１０から削除する。
【００７３】
なお、この共通ＸＰａｔｈ２５０は一度処理したパスの評価を複数回行わないために使用する。従って、表式から取得した共通ＸＰａｔｈ２５０は、表式の評価後に行う探索条件または選択式の処理で使用する（詳細は図１９、図２０で説明する）。探索条件から取得した共通ＸＰａｔｈ２５０は、探索条件評価後に行う選択式の評価で使用する（詳細は図２０で説明する）。
【００７４】
（ＸＰａｔｈの文字列比較）
ここまでは、ＸＭＬスキーマ３００またはインデクス構成情報４００を用いて共通ＸＰａｔｈ２５０を取得する場合を述べた。しかし、ＸＭＬスキーマ３００、インデクス構成情報４００がない場合は、ＳＱＬ文中からＸＰａｔｈを示す文字列を切り出し、文字列比較を行うことにより共通ＸＰａｔｈ２５０を取得することも可能である。
【００７５】
（アクセスプラン決定処理）
次に、図７のステップＳ７０７に示すアクセスプラン決定処理について具体的に説明する。図１６はアクセスプラン決定部が共通ＸＰａｔｈを利用したアクセスプランを決定する際の流れを示したフローチャートである。アクセスプラン決定部１３２は共通ＸＰａｔｈ２５０およびＳＱＬ文２００を分解した選択式２０１、表式２０２、探索条件２０３を取得とする。なお、ここでは表式の評価、探索条件評価、行ＩＤ返却、共通ＸＰａｔｈ２５０が示すデータ格納位置情報返却、行ＩＤに基づきデータ取得、データ格納位置情報６００に基づき共通ＸＰａｔｈ２５０が示すノード以下のデータ取得、および選択式のＸＰａｔｈ評価を行う手順をアクセスプランとする。
【００７６】
図１６に示すように、まず、アクセスプラン決定部１３２は、表式を評価するアクセスコストを計算し（ステップＳ１６０１）、探索条件を評価するアクセスコストを計算し（ステップＳ１６０２）、選択式を評価するアクセスコストを計算する（ステップＳ１６０３）。そして、アクセスプラン決定部１３２は、ステップＳ１６０１〜Ｓ１６０３で求めた全アクセスコストを合計し、アクセスプラン全体のアクセスコストを計算する（ステップＳ１６０４）。
【００７７】
次に、アクセスプラン決定部１３２は、メインメモリ１０上に保持した共通ＸＰａｔｈ２５０があるか否かを判定する（ステップＳ１６０５）。共通ＸＰａｔｈ２５０があれば（ステップＳ１６０５→Ｙｅｓ）、アクセスプラン決定部１３２は、共通ＸＰａｔｈ２５０を読み出す（ステップＳ１６０６）。続いて、アクセスプラン決定部１３２は、共通ＸＰａｔｈ２５０に含まれるノード数をカウントする（ステップＳ１６０７）。そして、アクセスプラン決定部１３２は、選択式および探索条件の評価時に評価を省略できるノード数に応じたアクセスコストを計算する（ステップＳ１６０８）。続いて、アクセスプラン決定部１３２は、共通ＸＰａｔｈ２５０が示すデータ格納位置情報を取得するアクセスコストを計算する（ステップＳ１６０９）。次に、アクセスプラン決定部１３２は、共通ＸＰａｔｈが示すデータを取得するアクセスコストを計算する（ステップＳ１６１０）。続いて、アクセスプラン決定部１３２は、表式を評価するアクセスコストを計算し（ステップＳ１６１１）、探索条件を評価するアクセスコストを計算し（ステップＳ１６１２）、選択式を評価するアクセスコストを計算する（ステップＳ１６１３）。
【００７８】
次に、アクセスプラン決定部１３２は、ステップＳ１６０８〜ステップＳ１６１３で求めた全アクセスコストを合計し、アクセスプラン全体のアクセスコストを計算する（ステップＳ１６１４）。続いて、アクセスプラン決定部１３２は、全ての共通ＸＰａｔｈ２５０についてステップＳ１６０７〜Ｓ１６１４までの処理を行ったか否かを判断する（ステップＳ１６１５）。まだ処理していない共通ＸＰａｔｈ２５０がある場合には（ステップＳ１６１５→Ｎｏ）、ステップ１６０７に戻り処理を続ける。一方、全ての共通ＸＰａｔｈについてのアクセスコストが計算済みであれば（ステップＳ１６１５→Ｙｅｓ）、次のステップＳ１６１６へ進む。
【００７９】
一方、ステップＳ１６０５において、メインメモリ１０上に保持した共通ＸＰａｔｈ２５０がない場合は（ステップＳ１６０５→Ｎｏ）、次のステップＳ１６１６へ進む。次に、アクセスプラン決定部１３２は、ステップＳ１６０４およびステップＳ１６１４で算出したアクセスプランそれぞれのアクセスコストの内、アクセスコストが最小のものをアクセスプランとして決定する（ステップＳ１６１６）。そして、アクセスプラン決定部１３２は、決定したアクセスプランを、インタプリタが実行できる中間コードに変換する（ステップＳ１６１７）。
【００８０】
図１０のアクセスコストを比較した例を用いて、具体的に説明する。アクセスプラン決定部１３２は、例えば、図５で定められたアクセスコストをもとに計算するものとする。図１０に示すように、共通ＸＰａｔｈ２５０を使用してアクセスプランを設定する場合（プラン１）、アクセスプラン決定部１３２は、探索条件のＸＰａｔｈ評価「２０００」、行ＩＤ返却「１０」、共通ＸＰａｔｈ２５０が示すノードのデータ格納位置情報返却「１０」、行ＩＤからデータ取得「１０００」、データ格納位置情報を用いて共通ＸＰａｔｈ２５０が示すノード以降のデータ取得「１０」、共通ＸＰａｔｈ２５０が示すノード以降の選択式のＸＰａｔｈ評価「５００」を行うので、全体のアクセスコストは全てを合算して「３５３０」と算出する。一方、共通ＸＰａｔｈ２５０を使用しない場合（プラン２）、アクセスプラン決定部１３２は、探索条件のＸＰａｔｈ評価「２０００」、行ＩＤ返却「１０」、行ＩＤからのデータ取得「１０００」、ルートノード以降の選択式のＸＰａｔｈ評価「１０００」を行うので、全体のアクセスコストは全てを合算して「４０１０」となる。アクセスプラン決定部１３２は、このように、共通ＸＰａｔｈ２５０を用いたアクセスプランのアクセスコストの合計値と、共通ＸＰａｔｈ２５０を使用しないアクセスプランのアクセスコストの合計値とを比較した上で、アクセスコストの合計値が最小のものアクセスプランとして決定する。
【００８１】
（アクセスプラン実行処理）
図７のステップＳ７０８に示すアクセスプラン実行処理について具体的に説明する。
図１７は、図１に示すアクセスプラン決定部で決定したアクセスプランに基づいて、ＳＱＬ実行部がＳＱＬ文の処理を実行する全体の処理の流れを示す概念図である。なお、図１７（ａ）は、データベースアクセス部、探索条件評価部、選択式実行部が行う処理の流れを示すフローチャートである。また、図１７（ｂ）は、図１７（ａ）に対応した実際のデータに基づいた処理を説明するための概念図である。なお、ここでは図２に示すＳＱＬ文２００がデータベース管理装置１に入力され、共通ＸＰａｔｈ２５０として、‘book_info/contents/chapter1’が抽出された場合として説明する。
【００８２】
図１７（ａ）に示すように、まずデータベースアクセス部１４１（図１参照）は、補助記憶装置４０に記憶されているＸＭＬデータ７００のうち、表（ＢＯＯＫ＿ＴＢＬ）にアクセスする（ステップＳ１７０１）。次に、探索条件評価部１４２は、探索条件の評価を行う（ステップＳ１７０２）。そして、探索条件の評価が真となった行の行ＩＤ６２０（＃１，＃３，…）を取得し（ステップＳ１７０３）、共通ＸＰａｔｈ２５０が示すノードの位置情報６３０を取得する（ステップＳ１７０４）。そして、取得した行ＩＤ６２０と位置情報６３０とを示すデータ格納位置情報６００をメインメモリ１０上に保持する。
【００８３】
次に、選択式実行部１４３は、データ格納位置情報６００に格納されている行ＩＤ６２０からデータを取得し（ステップＳ１７０５）、メインメモリ１０上に展開する。そして、選択式実行部１４３は、データ格納位置情報６００に格納されている位置情報６３０を用いて、メインメモリ１０上に展開されているデータから、共通ＸＰａｔｈ２５０が示すノード以降のデータを取得する処理を行う（ステップＳ１７０６）。そして、選択式実行部１４３は、ルートノードから共通ＸＰａｔｈ２５０が示すノードまでの評価を行わず、選択式のＸＰａｔｈを共通ＸＰａｔｈ２５０で示すノード以降のデータに対して評価する（ステップＳ１７０７）。
【００８４】
次に、アクセスプラン実行処理において、データベースアクセス部１４１、探索条件評価部１４２、選択式実行部１４３のそれぞれが行う詳細な処理の流れを具体的に説明する。
【００８５】
（データベースアクセス処理）
図１８は、アクセスプランに基づき、図１のデータベースアクセス部がデータベースにアクセスする際の流れを示したフローチャートである。データベースアクセス部１４１には、アクセスプラン決定部１３２が作成した中間コードが入力される。
【００８６】
図１８に示すように、まずデータベースアクセス部１４１は、表式２０２に示される表にアクセスする（ステップＳ１８０１）。次に、データベースアクセス部１４１は、表式に含まれるＸＰａｔｈを評価する（ステップＳ１８０２）。そして、データベースアクセス部１４１は、共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があるか否かを判定する（ステップＳ１８０３）。共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があれば（ステップＳ１８０３→Ｙｅｓ）、データベースアクセス部１４１は、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００を取得し、メインメモリ１０上に保持する（ステップＳ１８０４）。一方、データ格納位置情報６００の取得指示がなければ（ステップＳ１８０３→Ｎｏ）、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００を取得せず、ステップＳ１８０５へ進む。そして、データベースアクセス部１４１は、表式２０２中の全てのＸＰａｔｈを評価したか否かを判断する（ステップＳ１８０５）。表式２０２中のＸＰａｔｈにおいて評価していないＸＰａｔｈがあれば（ステップＳ１８０５→Ｎｏ）、ステップＳ１８０２に戻り処理を続ける。表式２０２中の全てのＸＰａｔｈを評価していれば（ステップＳ１８０５→Ｙｅｓ）、データベースアクセス部１４０での処理を終える。なお、表式２０２中にＸＰａｔｈがない場合は、データベースアクセス部１４１は、ステップＳ１８０１のみを行う。
【００８７】
データベースアクセス部１４１がステップＳ１８０４において取得する共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００は、探索条件評価部１４２または選択式実行部１４３で使用する。また、探索条件評価部１４２が取得する共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００（後記する図１９のステップＳ１９０７またはステップＳ１９１１）は、選択式実行部１４３で使用する。探索条件評価部１４２と選択式実行部１４３で使用するデータ格納位置情報６００は同じである必要はなく、アクセスコストが最小となるようにアクセスプラン決定部１３２により決定される。
【００８８】
（探索条件評価処理）
図１９は、アクセスプランに基づき、図１の探索条件評価部が探索条件を評価する際の流れを示したフローチャートである。探索条件評価部１４２は、データベースアクセス部１４１がアクセスしたデータ、およびメインメモリ１０上に保持したデータ格納位置情報６００が入力されている。
【００８９】
図１９に示すように、まず探索条件評価部１４２は、データベースアクセス部１４１で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００（図６参照）があるか否かを判定する（ステップＳ１９０１）。ここで、データ格納位置情報６００がある場合（ステップＳ１９０１→Ｙｅｓ）とは、表式にＸＰａｔｈを含み、そのＸＰａｔｈと探索条件のＸＰａｔｈから共通ＸＰａｔｈ２５０が抽出できる場合である。ただし、共通ＸＰａｔｈ２５０を抽出しても、アクセスコストが最小にならなければ、データ格納位置情報６００を取得しないアクセスプランとなることがある。
【００９０】
探索条件評価部１４２は、データ格納位置情報６００があれば（ステップＳ１９０１→Ｙｅｓ）、次にデータ格納位置情報６００に子孫ノード情報６４０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ１９０２）。そして、子孫ノード情報６４０が設定されていない場合は（ステップＳ１９０２→Ｎｏ）、ステップＳ１９０４へ進む。一方、子孫ノード情報６４０が設定されている場合には（ステップＳ１９０２→Ｙｅｓ）、ステップＳ１９０３へ進み、子孫ノード情報６４０に基づき、子孫ノードが存在するか否かを判断する（ステップＳ１９０３）。ここで、子孫ノード情報６４０により子孫ノードが存在しないと判断した場合は（ステップＳ１９０３→Ｎｏ）、データの読み込みを行わずステップＳ１９０８へ進む。一方、子孫ノード情報６４０により子孫ノードが存在すると判断した場合には（ステップＳ１９０３→Ｙｅｓ）、ステップＳ１９０４へ進む。
【００９１】
このように、子孫ノード情報６４０をデータ格納位置情報６００として設定することにより、子孫ノード情報６４０で子孫ノードが存在しない場合は（ステップＳ１９０３→Ｎｏ）、探索条件の処理において、共通ＸＰａｔｈ２５０で指定されたノード以降の子孫ノードのデータを読み込まないため、探索時間を短縮することができる。
【００９２】
次に、探索条件評価部１４２は、データ格納位置情報６００にノードテスト情報６５０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ１９０４）。そして、ノードテスト情報６５０が設定されていない場合には（ステップＳ１９０４→Ｎｏ）、ステップＳ１９０６へ進む。一方、ノードテスト情報６５０が設定されている場合には（ステップＳ１９０４→Ｙｅｓ）、ステップＳ１９０５へ進み、ノードテスト情報６５０に基づき、ノードテストに合致するか否かを判断する（ステップＳ１９０５）。ここで、ノードテスト情報６５０によりノードテストに合致しないと判断された場合は（ステップＳ１９０５→Ｎｏ）、データの読み込みを行わずステップＳ１９０８へ進む。一方、ノードテスト情報６５０により、ノードテストに合致すると判断された場合には（ステップＳ１９０５→Ｙｅｓ）、ステップＳ１９０６の処理へ進む。
【００９３】
このように、ノードテスト情報６５０をデータ格納位置情報６００として設定することにより、共通ＸＰａｔｈ２５０が示すノードがノードテスト６５０に合致しない場合は（ステップＳ１９０５→Ｎｏ）、探索条件の処理において、そのノードが示すデータを読み込まないため、探索時間を短縮することができる。
【００９４】
次に、ステップＳ１９０６において、探索条件評価部１４２は、データ格納位置情報６００から共通ＸＰａｔｈ２５０が示すノード以降のデータを読み込む（ステップＳ１９０６）。そして、読み込んだデータを用いて、探索条件評価部１４２が探索条件を評価する（ステップＳ１９０７）。続いて、探索条件評価部１４２は、共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があるか否かを判定する（ステップＳ１９０８）。データ格納位置情報６００の取得指示があれば（ステップＳ１９０８→Ｙｅｓ）、探索条件評価部１４２は、データ格納位置情報６００を取得し、メインメモリ１０上に保持する（ステップＳ１９０９）。一方、データ格納位置情報６００の取得指示がなければ（ステップＳ１９０８→Ｎｏ）、ステップＳ１９１０へ進む。続いて、探索条件評価部１４２は、全ての探索条件を評価したか否かを判断する（ステップＳ１９１０）。そして、評価していない探索条件がある場合には（ステップＳ１９１０→Ｎｏ）、ステップＳ１９０２へ戻り処理を続ける。一方、全ての探索条件を評価していれば（ステップＳ１９１０→Ｙｅｓ）、処理を終える。
【００９５】
一方、ステップＳ１９０１において、データベースアクセス部１４１で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００がなければ（ステップＳ１９０１→Ｎｏ）、探索条件評価部１４２は、共通ＸＰａｔｈ２５０を用いずに、探索条件の評価を行う（ステップＳ１９１１）。次に、探索条件評価部１４２は、共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があるか否かを判定する（ステップＳ１９１２）。データ格納位置情報６００の取得指示があれば（ステップＳ１９１２→Ｙｅｓ）、探索条件評価部１４２は、データ格納位置情報６００を取得し、メインメモリ１０上に保持する（ステップＳ１９１３）。一方、データ格納位置情報６００の取得指示がなければ（ステップＳ１９１２→Ｎｏ）、ステップＳ１９１４へ進む。続いて、探索条件評価部１４２は、全ての探索条件を評価したか否かを判断する（ステップＳ１９１４）。そして、評価していない探索条件がある場合には（ステップＳ１９１４→Ｎｏ）、ステップＳ１９１１へ戻り処理を続ける。一方、全ての探索条件を評価していれば（ステップＳ１９１４→Ｙｅｓ）、処理を終える。
【００９６】
（選択式評価処理）
図２０はアクセスプランに基づき、図１の選択式実行部が選択式のＸＰａｔｈを評価する際の流れを示すフローチャートである。選択式実行部１４３は、データベースアクセス部１４１または探索条件評価部１４２でメインメモリ７００上に保持したデータ格納位置情報６００が入力されている。
【００９７】
図２０に示すように、まず選択式実行部１４３は、データベースアクセス部１４１または探索条件評価部１４２で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００があるか否かを判定する（ステップＳ２００１）。
【００９８】
ここで、データ格納位置情報６００がある場合（ステップＳ２００１→Ｙｅｓ）とは、次の３つの場合がある。（１） 表式２０２にＸＰａｔｈを含み、そのＸＰａｔｈと選択式２０１のＸＰａｔｈとから共通ＸＰａｔｈ２５０が抽出できる場合。（２）探索条件２０３にＸＰａｔｈを含み、そのＸＰａｔｈと選択式２０１のＸＰａｔｈとから共通ＸＰａｔｈ２５０が抽出できる場合。（３）表式２０２にＸＰａｔｈを含み、探索条件２０３にもＸＰａｔｈを含み、それらのＸＰａｔｈと選択式２０１のＸＰａｔｈとから共通ＸＰａｔｈ２５０が抽出できる場合である。この３つの場合の中で、どの共通ＸＰａｔｈ２５０を使用するかは、アクセスプラン決定部１３２により決定されたアクセスプランに基づく。従って、共通ＸＰａｔｈ２５０を抽出しても、アクセスコストが最小にならなければ、データ格納位置情報６００を取得しないアクセスプランとなることがある。
【００９９】
図２０に戻り、選択式実行部１４３は、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００があれば（ステップＳ２００１→Ｙｅｓ）、次にデータ格納位置情報６００に子孫ノード情報６４０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ２００２）。そして、子孫ノード情報６４０が設定されていない場合は（ステップＳ２００２→Ｎｏ）、ステップＳ２００４へ進む。一方、子孫ノード情報６４０が設定されている場合には（ステップＳ２００２→Ｙｅｓ）、ステップＳ２００３へ進み、子孫ノード情報６４０に基づき、子孫ノードが存在するか否かを判断する（ステップＳ２００３）。ここで、子孫ノード情報６４０により子孫ノードが存在しないと判断した場合は（ステップＳ２００３→Ｎｏ）、データの読み込みを行わずステップＳ２００８へ進む。一方、子孫ノード情報６４０により子孫ノードが存在すると判断した場合には（ステップＳ２００３→Ｙｅｓ）、ステップＳ２００４へ進む。
【０１００】
このように、子孫ノード情報６４０をデータ格納位置情報６００として設定することにより、子孫ノード情報６４０で子孫ノードが存在しない場合は（ステップＳ２００３→Ｎｏ）、選択式の処理において、共通ＸＰａｔｈ２５０で指定されたノード以降の子孫ノードのデータを読み込まないため、探索時間を短縮することができる。
【０１０１】
次に、選択式実行部１４３は、データ格納位置情報６００にノードテスト情報６５０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ２００４）。そして、ノードテスト情報６５０が設定されていない場合には（ステップＳ２００４→Ｎｏ）、ステップＳ２００６へ進む。一方、ノードテスト情報６５０が設定されている場合には（ステップＳ２００４→Ｙｅｓ）、ステップＳ２００５へ進み、ノードテスト情報６５０に基づき、ノードテストに合致するか否かを判断する（ステップＳ２００５）。ここで、ノードテスト情報６５０によりノードテストに合致しないと判断された場合は（ステップＳ２００５→Ｎｏ）、データの読み込みを行わずステップＳ２００８へ進む。一方、ノードテスト情報６５０により、ノードテストに合致すると判断された場合には（ステップＳ２００５→Ｙｅｓ）、ステップＳ２００６の処理へ進む。
【０１０２】
このように、ノードテスト情報６５０をデータ格納位置情報６００として設定することにより、共通ＸＰａｔｈ２５０が示すノードがノードテスト６５０に合致しない場合は（ステップＳ２００５→Ｎｏ）、選択式の処理において、そのノードが示すデータを読み込まないため、探索時間を短縮することができる。
【０１０３】
次に、ステップＳ２００６において、選択式実行部１４３は、データ格納位置情報６００から共通ＸＰａｔｈ２５０が示すノード以降のデータを読み込む（ステップＳ２００６）。次に、読み込んだデータを用いて選択式実行部１４３は、共通ＸＰａｔｈ２５０が示すノード以降の選択式のＸＰａｔｈを評価する（ステップＳ２００７）。続いて、選択式実行部１４３は、全ての選択式を評価したか否かを判断する（ステップＳ２００８）。そして、評価していない選択式がある場合には（ステップＳ２００８→Ｎｏ）、ステップＳ２００２へ戻り処理を続ける。一方、全ての選択式を評価していれば（ステップＳ２００８→Ｙｅｓ）、処理を終える。
【０１０４】
一方、ステップＳ２００１において、データベースアクセス部１４１または探索条件評価部１４２で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００がなければ（ステップＳ２００１→Ｎｏ）、選択式実行部１４３は、補助記憶部４０からＸＭＬデータ７００を読み込む（ステップＳ２００９）。続いて、選択式実行部１４３は、読み込んだデータを用いて選択式のＸＰａｔｈを評価する（ステップＳ２０１０）。次に、選択式実行部１４３は、全ての選択式を評価したか否かを判断する（ステップＳ２０１１）。そして、評価していない選択式がある場合には（ステップＳ２０１１→Ｎｏ）、ステップＳ２０１０へ戻り処理を続ける。一方、全ての選択式を評価していれば（ステップＳ２０１１→Ｙｅｓ）、処理を終える。
【０１０５】
このようにすることで、本実施形態に係るデータベース管理方法、データベース管理装置およびプログラムは、ルートノードから共通パスに示されるノードまで辿る処理を排除し、構造化データの検索時間を短縮することができる。
【図面の簡単な説明】
【０１０６】
【図１】本実施形態に係るデータベース管理システムの構成を示す機能ブロック図である。
【図２】実施形態に係るデータベース管理装置に入力されるＳＱＬの一例を示す図である。
【図３】本実施形態に係るＸＭＬスキーマの一例を示す図である。
【図４】本実施形態に係るインデクス構成情報の一例を示す図である。
【図５】本実施形態に係るアクセスコスト設定情報の一例を示す図である。
【図６】本実施形態に係るデータ格納位置情報の一例を示す図である。
【図７】本実施形態に係るデータベース管理方法の処理の流れを示すフローチャートである。
【図８】本実施形態に係るデータベース管理装置に入力されるＳＱＬ文中にヒント情報が含まれている例を示す図である。
【図９】本実施形態に係る共通ＸＰａｔｈを木構造で表現した図である。
【図１０】本実施形態に係るデータベース管理方法においてアクセスコストが最小のアクセスプランの決定を説明するための図である。
【図１１】本実施形態に係るデータベース管理方法において、ＸＭＬスキーマを用いて、探索条件および選択式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１２】本実施形態に係るデータベース管理方法において、ＸＭＬスキーマを用いて、表式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１３】本実施形態に係るデータベース管理方法において、インデクス構成情報を用いて、探索条件および選択式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１４】本実施形態に係るデータベース管理装置において、インデクス構成情報を用いて、表式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１５】本実施形態に係るデータベース管理方法において、共通ＸＰａｔｈを抽出する処理の流れを示すフローチャートである。
【図１６】本実施形態に係るデータベース管理方法において、共通ＸＰａｔｈを利用したアクセスプランを決定する際の流れを示すフローチャートである。
【図１７】本実施形態に係るデータベース管理方法において、アクセスプランに従い、ＳＱＬを実行する概念を説明するための図である。
【図１８】本実施形態に係るデータベース管理方法において、データベースにアクセスする際の流れを示したフローチャートである。
【図１９】本実施形態に係るデータベース管理方法において、探索条件を評価する際の流れを示したフローチャートである。
【図２０】本実施形態に係るデータベース管理方法において、選択式のＸＰａｔｈを評価する際の流れを示すフローチャートである。
【符号の説明】
【０１０７】
１ データベース管理装置
５ 情報処理装置
６ ネットワーク
７ データベース管理システム
１０，５０ メインメモリ
２０，５１ ＣＰＵ
３０，５２ 通信部
４０ 補助記憶部
５５ アプリケーション処理部
１００ データベース管理部
１１０ ＳＱＬ解析部
１１１ ＳＱＬ分解部
１１２ ヒント情報解析部
１２０ 定義情報解析部
１２１ ＸＭＬスキーマ解析部
１２２ インデクス構成情報解析部
１３０ ＳＱＬ最適化部
１３１ 共通ＸＰａｔｈ抽出部
１３２ アクセスプラン決定部
１４０ ＳＱＬ実行部
１４１ データベースアクセス部
１４２ 探索条件評価部
１４３ 選択式実行部
２００ ＳＱＬ文
２１０ 選択式から取得した最短経路のＸＰａｔｈ
２２０ 表式から取得した最短経路のＸＰａｔｈ
２３０ 探索条件から取得した最短経路のＸＰａｔｈ
２５０ 共通ＸＰａｔｈ
３００ ＸＭＬスキーマ
４００ インデクス構成情報
５００ アクセスコスト設定情報
６００ データ格納位置情報
７００ ＸＭＬデータ
８００ ヒント情報
【技術分野】
【０００１】
本発明は、データベース管理技術に関する。
【背景技術】
【０００２】
現在、企業間の電子商取引や電子申請システム、電子カルテシステムなどで、様々な情報を共有する手段の１つとして、利便性、拡張性に特徴があるＸＭＬ（eXtensible Markup Language）データをデータベースに格納する機会が増えてきている。また、そのＸＭＬにおいて、Ｗ３Ｃ（World Wide Web Consortium）勧告で公開されたＸＰａｔｈは、ＸＭＬデータの特定部分を指し示すパス言語であり、ＸＭＬデータに対する問い合わせ等において重要な役割を果たしている。
【０００３】
このＸＰａｔｈを処理するには、ルートノードから順に木構造のノードを辿って行う。従って、木構造を辿る処理では、インデクス等でノードを特定できる場合を除き、全ノードを順に辿るため、ＸＰａｔｈおよび木構造の指定によっては、検索に非常に時間がかかってしまう。
【０００４】
また、データベース管理システム（ＤＢＭＳ：DataBase Management System）にＸＭＬデータをそのまま列データとして格納し、従来資産のＲＤＢＭＳ（Relational ＤＢＭＳ）を活用する動きも広まってきている。そして、このＲＤＢＭＳのＸＭＬ列を検索する際には、ＳＱＬ／ＸＭＬを用いる技術がある（例えば、非特許文献１参照）。
【０００５】
従来のＲＤＢＭＳの検索の仕組みでは、まず、入力されるＳＱＬ文を、選択式、表式および探索条件に分解する。そして、表式に示された表にアクセスして構造化データの表を指定し、探索条件でこの構造化データに所定の要素が含まれているか否かを判断し、所定の要素が含まれている構造化データについて選択式に指定された処理を実行し、得られた結果を検索を要求したアプリケーションに返却する。
【非特許文献１】Jim Melton and Stephen Buxton, “Querying XML-XQuery, XPath, and SQL/XML in Context”，Morgan Kaufmann Pablishers，523-582，2006
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、同じＸＭＬデータに対してＸＰａｔｈをＳＱＬ文中に複数指定している場合、複数のＸＰａｔｈの中に関連性をもつものが含まれることが多い。例えば、探索条件のＸＰａｔｈで表式中の特定行のデータを絞り込み、絞り込んだデータの中から選択式のＸＰａｔｈで特定の一部分を射影する場合などにおいては、探索条件のＸＰａｔｈ、表式のＸＰａｔｈ、および選択式のＸＰａｔｈには関連性がある。
【０００７】
従来のＲＤＢＭＳの技術では、選択式、表式および探索条件に関連性のあるＸＰａｔｈが存在する場合でも、選択式、表式および探索条件のそれぞれの処理が別ステップで行われるため、共通のＸＰａｔｈを複数回評価しなければならない。そのため、ＸＰａｔｈが複雑で評価に時間がかかるほど、検索に時間がかかってしまう。
【０００８】
このような背景に鑑みて本発明がなされたのであり、本発明は、構造化データの検索時間を短縮することができるデータベース管理方法、データベース管理装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
前記課題を解決するため、本発明のデータベース管理方法、データベース管理装置およびプログラムは、構造化データを処理するためのＳＱＬ文から、処理対象となるデータの格納位置を示すパスの全てを抽出し、パスが複数抽出された場合に、それぞれのパスを比較して共通部分を共通パスとして抽出し、その共通パスが示す格納位置以降のデータについてＳＱＬ文に基づく処理を行うことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ルートノードから共通パスに示されるノードまで辿る処理を排除し、構造化データの検索時間を短縮することができるデータベース管理方法、データベース管理装置およびプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１１】
次に、本発明を実施するための最良の形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
【００１２】
なお、本発明において、構造化データは、ＸＭＬデータ、ＳＧＭＬ（Standard Generalized Markup Language）データ等を含むが、本実施形態においては、ＸＭＬデータを例として説明する。
【００１３】
図１は、本実施形態に係るデータベース管理システムの構成例を示す機能ブロック図である。図１に示すように、データベース管理システム７は、情報処理装置５と、ネットワーク６を介して情報処理装置５に通信可能に接続されているデータベース管理装置１とを含んで構成される。
【００１４】
ここで、情報処理装置５は、メインメモリ５０と、ＣＰＵ（Central Processing Unit）５１と、通信部５２とを含んで構成される。メインメモリ５０上にはアプリケーションプログラムを制御するアプリケーション処理部５５がプログラムとして読み込まれ、ＣＰＵ５１を介して処理が実行される。このアプリケーション処理部５５が、データベース管理装置１にＸＭＬデータの問い合わせを行うと、通信部５２を介してネットワーク６経由で問い合わせ要求がデータベース管理装置１へ送られる。
【００１５】
データベース管理装置１は、メインメモリ１０と、ＣＰＵ２０と、通信部３０と、補助記憶部４０とを含んで構成される。
【００１６】
ＣＰＵ２０は、データベース管理装置１の全体の制御および演算を行う。また、通信部３０は、ネットワーク６を介して情報処理装置５から、ＳＱＬ文等のデータを受信する。
【００１７】
補助記憶部４０は、フラッシュメモリ、ハードディスク等の記憶手段からなり、後記するＸＭＬデータ７００、ＸＭＬスキーマ３００、インデクス構成情報４００等を記憶する。
【００１８】
メインメモリ１０はＲＡＭ（Random Access Memory）等の一次記憶装置からなり、メインメモリ１０上にはデータベース管理部１００がプログラムとして読み込まれている。また、メインメモリ１０は、データベース管理部１００が処理する、共通ＸＰａｔｈ２５０、データ格納位置情報６００等（詳細は後記する）を一時的に保存する。
【００１９】
データベース管理部１００は、記憶部４０に記憶されたＸＭＬデータ７００の処理に関する制御を行い、ＳＱＬ解析部１１０と、定義情報解析部１２０と、ＳＱＬ最適化部１３０と、ＳＱＬ実行部１４０と、制御部１５０とを含んで構成される。なお、このデータベース管理部１００は、例えばデータベース管理装置１の補助記憶部４０に記憶されたプログラムを、ＣＰＵ２０がメインメモリ１０に展開し実行することで実現される。
【００２０】
ＳＱＬ解析部１１０は、通信部３０を介して情報処理装置５のアプリケーション処理部５５から取得したＳＱＬ文を解析する。このＳＱＬ解析部１１０は、ＳＱＬ分解部１１１と、ヒント情報解析部１１２とを含んで構成される。
【００２１】
ＳＱＬ分解部１１１は、取得したＳＱＬ文を、選択式、表式および探索条件に分解する。なお、ＸＭＬデータ７００の検索処理に用いられるＳＱＬ文には、ＸＭＬデータ７００の表を指定する表式およびＸＭＬデータ７００を所定の要素の中から射影する選択式を少なくとも含み、さらに対象となるＸＭＬデータ７００の中から特定の行を取り出す探索条件を含むことができる。
【００２２】
図２は、図１の情報処理装置のアプリケーション処理部からネットワークを介してＳＱＬ解析部が取得する、ＳＱＬ文の一例を示す図である。図２に示すように、ＳＱＬ文２００は、ＳＥＬＥＣＴ句で指定される選択式２０１と、ＦＲＯＭ句で指定される表式２０２と、ＷＨＥＲＥ句で指定される探索条件２０３とを含んでいる。また、ＳＱＬ文２００は、選択式２０１、表式２０２および探索条件２０３の他に、後記するヒント情報を含むことができる。なお、このヒント情報は、共通ＸＰａｔｈ２５０を使用してＳＱＬ文の処理を行うか否かを指定する情報であり、詳細は後記する（図８参照）。
【００２３】
図１に戻り、ヒント情報解析部１１２は、後記する共通ＸＰａｔｈ２５０を用いて処理を行うか否かを指定するヒント情報がＳＱＬ文に含まれているか否かを解析し、ヒント情報が含まれている場合には、その指示に従い、共通ＸＰａｔｈ２５０を用いてＸＭＬデータ７００の処理を行うか否かを判断する。
【００２４】
次に、定義情報解析部１２０は、ＳＱＬ分解部１１１で分解されたＳＱＬ文から、処理対象となるデータの格納位置を指定するＸＰａｔｈを示す文字列を切り出す。そして、定義情報解析部１２０は、後記するＸＭＬスキーマ３００またはインデクス構成情報４００に基づき、ルートノードから処理対象となるデータの格納位置までの最短経路のＸＰａｔｈを取得する。本例では、最短経路を例にしているが、必ずしも最短経路に限定されるものではなく、より短い経路の方が効果は高くなるが、経路を記憶して利用することで検索実行時間は短縮される。この定義情報解析部１２０は、ＸＭＬスキーマ解析部１２１と、インデクス構成情報解析部１２２とを含んで構成される。
【００２５】
ＸＭＬスキーマ解析部１２１は、ＳＱＬ文からＸＰａｔｈを示す文字列を切り出し、切り出したＸＰａｔｈを示す文字列それぞれが、省略記法で指定されている場合には、フルパス記法に変換し、逆文書順の記法で指定されている場合には、文書順の記法に変換する。そして、ＸＭＬスキーマ解析部１２１は、変換したＸＰａｔｈを示す文字列と、補助記憶部４０に記憶されたＸＭＬスキーマ３００とを、ルートノードからＸＰａｔｈで指定されるノードまで順に突き合せ、選択式から取得した最短経路のＸＰａｔｈ２１０、表式から取得した最短経路のＸＰａｔｈ２２０および探索条件から取得した最短経路のＸＰａｔｈ２３０を取得し、メインメモリ１０上に保持する。
【００２６】
図３は、図１の補助記憶部に記憶されるＸＭＬスキーマの一例を示す図である。図３（ａ）に示すように、ＸＭＬスキーマ３００によりＸＭＬ文書の構造が定義される。例えば、符号３０１に示す定義文は、ルートノードの要素が「book_info」であることを宣言し、符号３０２に示す定義文は、子要素として「title」「price」「author」「contents」があることを宣言する。また、「contents」の要素をさらにref属性で宣言し、その参照先として符号３０３に示す定義文が記述され、「contents」の子要素として、「foreword」「chapter」があることを宣言する。そして、さらに「chapter」の子要素として、符号３０４に示す定義文が記述され「introduction」「section」「summery」があることを宣言する。
【００２７】
図３（ｂ）は、図３（ａ）のＸＭＬスキーマで定義された内容を木構造として表現した図である。ＸＭＬスキーマ３００をメインメモリ１０上に展開すると、ルートノードからＸＰａｔｈで指定されているノードまでを探索することができる。従って、ＸＭＬスキーマ解析部１２１は、選択式、表式および探索条件に含まれるＸＰａｔｈを示す文字列とＸＭＬスキーマ３００とを、ルートノードからＸＰａｔｈで指定されるノードまで文書順に突き合せ、最短経路のＸＰａｔｈを特定することができる。
【００２８】
図１に戻り、インデクス構成情報解析部１２２は、ＳＱＬ文からＸＰａｔｈを示す文字列を切り出し、切り出されたＸＰａｔｈを示す文字列それぞれが、省略記法で指定されている場合には、フルパス記法に変換し、逆文書順の記法で指定されている場合には、文書順の記法に変換する。そして、インデクス構成情報解析部１２２は、変換したＸＰａｔｈを示す文字列と、補助記憶部４０に記憶されたインデクス構成情報４００とを、ルートノードからＸＰａｔｈで指定されるノードまで順に突き合せ、選択式から取得した最短経路のＸＰａｔｈ２１０、表式から取得した最短経路のＸＰａｔｈ２２０および探索条件から取得した最短経路のＸＰａｔｈ２３０を取得し、メインメモリ１０上に保持する。
【００２９】
図４は、図１の補助記憶部に記憶されるインデクス構成情報の一例を示す図である。図４（ａ）は、本実施形態に係るインデクス構成情報の一例を示す図である。図４（ｂ）は、図４（ａ）に示したインデクス構成情報の一例を木構造で表現した図である。図４（ａ）に示すように、インデクス定義が指定されると、データベース管理部１００は、インデクス定義４１０からインデクス管理情報４２０を生成する。このインデクス管理情報４２０は、インデクス名（INDX_NAME）、表名（TBL_NAME）、列名（COL_NAME）、データ型（DATA_TYPE）と共に、インデクス定義時に指定したキーを特定するＸＰａｔｈ（以下、インデクス構成情報４００という）を含み、補助記憶部４０に記憶される。
【００３０】
図４（ｂ）は、例えば、インデクス構成情報４００が‘/book_info/contents’の場合に、インデクスキーを特定するＸＰａｔｈの内容を木構造で表現した図である。インデクス構成情報４００を図１のメインメモリ１０上に展開すると、ルートノードからＸＰａｔｈで指定されるノードまで探索することができる。従って、ＸＭＬスキーマ３００が補助記憶部４０に記憶されていない場合においても、インデクス構成情報解析部１２２は、選択式、表式および探索条件のＸＰａｔｈを示す文字列とインデクス構成情報４００で定義される木構造とを、ルートノードからＸＰａｔｈで指定されるノードまで文書順に突き合せ、最短経路のＸＰａｔｈを特定することができる。
【００３１】
図１に戻り、ＳＱＬ最適化部１３０は、定義情報解析部１２０で抽出された選択式、表式および探索条件それぞれの最短経路のＸＰａｔｈを示す文字列から、共通部分を共通ＸＰａｔｈ２５０として抽出し、抽出した共通ＸＰａｔｈ２５０を用いて、アクセスプランを決定する。このＳＱＬ最適化部１３０は、共通ＸＰａｔｈ抽出部１３１とアクセスプラン決定部１３２とを含んで構成される。
【００３２】
共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した探索条件から取得した最短経路のＸＰａｔｈ２３０、選択式から取得した最短経路のＸＰａｔｈ２１０および表式から取得した最短経路のＸＰａｔｈ２２０を読み出し、ＸＰａｔｈを下位のノードからルートノードに向かって突き合せる。なお、このとき、ＸＰａｔｈをルートノードから順に突き合せるようにしてもよい。共通ＸＰａｔｈ抽出部１３１は、突き合せた結果、一致したＸＰａｔｈを共通ＸＰａｔｈ２５０としてメインメモリ１０上に保持する。
【００３３】
アクセスプラン決定部１３２は、共通ＸＰａｔｈ抽出部１３１が抽出した共通ＸＰａｔｈ２５０を用いて、アクセスコストが最小となるものをアクセスプランとして決定する。なお、本実施形態におけるアクセスプラン（「クエリプラン」ともいう）とは、表式の評価、探索条件の評価、行ＩＤ返却、共通ＸＰａｔｈ２５０が示すデータ格納位置情報返却、行ＩＤに基づきデータ取得、データ格納位置情報６００に基づき共通ＸＰａｔｈ２５０が示すノード以下のデータ取得、そして選択式のＸＰａｔｈ評価を行う手順をいう。また、本実施形態において、表式の評価とは、ＳＱＬ文中の表式に基づいて、構造化データの表にアクセスすることをいう。また、探索条件の評価とは、探索条件に示される所定の要素が条件を満たすか否かの「真」「偽」を判断することをいう。そして、選択式のＸＰａｔｈ評価とは、メインメモリ上に展開されている構造化データから、選択式に示される所定の要素が含まれているか否かを判断することをいう。
【００３４】
図５は、本実施形態における各処理のアクセスコストを示すアクセスコスト設定情報の一例を示す図である。図５に示すように、このアクセスコスト設定情報５００で示される各アクセスコストは、例えば当該処理内容の実行に要する処理時間に応じた相対値で予め設定しておくものである。例えば、表式のＸＰａｔｈ評価およびルートノード以降の探索条件のＸＰａｔｈ評価に要するアクセスコストは、補助記憶部４０にアクセスし条件評価を行うため、「２０００」と比較的大きい値が設定される。一方、探索条件のＸＰａｔｈ評価に要するアクセスコストおよび選択式のＸＰａｔｈ評価のアクセスコストは、共通ＸＰａｔｈ２５０が示すノード以降を評価する場合は、ルートノード以降を評価する場合に比べて、小さく設定される。これは、共通ＸＰａｔｈ２５０を使用することにより、評価を省略することができるノード数に応じて、アクセスコストが低減できる可能性があるからである。また、選択式のＸＰａｔｈ評価のアクセスコストは、メインメモリ１０上に格納されているデータを用いて行うため、表式のＸＰａｔｈ評価および探索条件のＸＰａｔｈ評価のアクセスコストに比べて小さく設定される。行ＩＤ返却および共通ＸＰａｔｈ２５０が示すノードのデータ格納位置情報返却に要するアクセスコストは、行ＩＤからのデータ取得に比べてデータ長が短いため、極めて小さい値となる。位置情報から共通ＸＰａｔｈ２５０が示すノードのデータ取得では、メインメモリ１０上に格納されたデータを用いるため、アクセスコストを小さく設定している。アクセスコストは、このようにそれぞれに設定されたアクセスコストを合算して求められ、共通ＸＰａｔｈ２５０の組合わせのうち、アクセスコストが最小となるものに、アクセスプランを決定する。
【００３５】
図１に戻り、ＳＱＬ実行部１４０は、アクセスプラン決定部１３２で決定したアクセスプランに基づいて、ＳＱＬを実行するものであり、データベースアクセス部１４１と、探索条件評価部１４２と、選択式実行部１４３とを含んで構成される。
【００３６】
データベースアクセス部１４１は、補助記憶部４０に記憶されているＸＭＬデータ７００のうち操作の対象となる表を指定する（例えば図２の表式２０２で指定される‘ＢＯＯＫ＿ＴＢＬ’）。また、探索条件評価部１４２は、表で示されるデータの探索条件の評価を行い、探索条件の評価が真となった行の行ＩＤおよび共通ＸＰａｔｈ２５０が示すノードの位置情報を取得し、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００（詳細は後記する図６参照）をメインメモリ１０上に保持する処理を行う。
【００３７】
選択式実行部１４３は、データ格納位置情報６００に格納されている行ＩＤからデータを取得し、メインメモリ１０上にデータを保持する。そして、選択式実行部１４３は、データ格納位置情報６００に格納されている位置情報を用いて、メインメモリ１０上に展開されているデータから、共通ＸＰａｔｈ２５０が示すノード以降のデータを取得する処理を行う。そして、ルートノードから、共通ＸＰａｔｈ２５０で示されるノードまでの評価を行わず、選択式のＸＰａｔｈを共通ＸＰａｔｈ２５０で示すノード以降のデータに対して評価を行う。
【００３８】
図６は、本実施形態におけるデータ格納位置情報の例を示す図である。図６（ａ）は、列情報、行ＩＤおよび位置情報がデータ格納位置情報として含まれる例を示す。図６（ｂ）は、さらに子孫ノード情報とノードテスト情報とがデータ格納位置情報として含まれる例を示す。図６（ａ）に示すように、データ格納位置情報６００は、共通ＸＰａｔｈ２５０が指定されている列を特定するための列情報６１０と、探索条件の評価が真になった行を特定するための行ＩＤ６２０と、共通ＸＰａｔｈ２５０が示すデータの位置情報６３０とを有する。また、表式のＸＰａｔｈ評価時に取得する場合のデータ格納位置情報６００も同様に、共通ＸＰａｔｈ２５０が指定されている列を特定するための列情報６１０と、探索条件が真になった行を特定するための行ＩＤ６２０と、共通ＸＰａｔｈ２５０が示すデータの位置情報６３０とを有する。
【００３９】
また、図６（ｂ）に示すように、このデータ格納位置情報６００は、列情報６１０、行ＩＤ６２０、データの位置情報６３０に加えて、共通ＸＰａｔｈ２５０の示すノードの子孫ノードの有無を識別する情報である子孫ノード情報６４０およびノードテストに合致したか否かを示す情報であるノードテスト情報６５０を含むことができる。
【００４０】
この子孫ノード情報６４０を用いることで、探索条件評価部１４２および選択式実行部１４３は、共通ＸＰａｔｈ２５０が示すノードに子孫ノードが存在する場合のみ、ＸＰａｔｈの評価を行う。従って、子孫ノードが存在しないと判断できる場合は、探索条件評価部１４２および選択式実行部１４３は、ＸＰａｔｈ評価を行わない。すなわち、探索条件評価部１４２は、条件判定を偽とする処理を行い、選択式実行部１４３はＮＵＬＬを返却する処理を行う。
【００４１】
また、共通ＸＰａｔｈ２５０の示すノードがノードテストに合致したか否かを示すノードテスト情報６５０を用いることにより、ノードテストに合致した場合にのみ探索条件評価部１４２および選択式実行部１４３はＸＰａｔｈの評価を行う。ノードテストに合致しない場合は、探索条件評価部は、条件判定を偽とする処理を行い、選択式実行部１４３は、ＮＵＬＬを返却する処理を行う。
【００４２】
次に、図１を参照しつつ、図７に沿って、本実施形態に係るデータベース管理方法の処理を説明する。図７は、入力されたＳＱＬ文からアクセスコストが最小となるアクセスプランを作成するまでの例を示している。なお、図７においては、図２に示すＳＱＬ文２００がデータベース管理装置１に入力されたものとして説明する。
【００４３】
まず、情報処理装置５（図１参照）のアプリケーション処理部５５を介してネットワーク６経由で、データベース管理装置１にＳＱＬ文２００が入力される（ステップＳ７０１）。ＳＱＬ文２００が入力されると、まず、ヒント情報解析部１１２の処理により、ＳＱＬ文２００の中に「共通ＸＰａｔｈ使用不可」のヒント情報が含まれているか否かを判断する（ステップＳ７０２）。そして、ＳＱＬ文２００の中に「共通ＸＰａｔｈ使用不可」のヒント情報は含まれていなければ（ステップＳ７０２→Ｎｏ）、ステップＳ７０３へ進む。一方、ＳＱＬ文の中に「共通ＸＰａｔｈ使用不可」のヒント情報が含まれていれば（ステップＳ７０２→Ｙｅｓ）、ステップＳ７０７へ進み、アクセスプランを決定処理を行う。
【００４４】
図８は、共通ＸＰａｔｈの使用の可否を指定するヒント情報が含まれているＳＱＬ文の例を示す図である。図８（ａ）は、共通ＸＰａｔｈを使用することを指示するヒント情報を含む例である。また、図８（ｂ）は、共通ＸＰａｔｈを使用しないこと指示するヒント情報を含む例である。
【００４５】
図８（ａ）に示すＳＱＬ文の中には、ヒント情報８００として、「ＷＩＴＨ ＸＰＡＴＨ句」が指定されている。この「ＷＩＴＨ ＸＰＡＴＨ句」は、このヒント情報８００で予め指定した共通ＸＰａｔｈ２５０を使用してアクセスプランを作成することを指示するものである。図８（ａ）の例においては、‘book_info/contents/chapter1’が共通ＸＰａｔｈ２５０として指定される。このようにヒント情報８００で共通ＸＰａｔｈ２５０を使用することが指示されると、アクセスプラン決定部１３２は、アクセスコストが最小でなくても、指定された共通ＸＰａｔｈ２５０を用いてアクセスプランを決定する。
【００４６】
このようにすることで、予め共通ＸＰａｔｈ２５０が分かっている場合に、ＳＱＬ実行部１４０（図１参照）は、ヒント情報８００で指定した共通ＸＰａｔｈ２５０を用いてＸＭＬデータ７００の検索をすることが可能となる。
【００４７】
また、図８（ｂ）に示すＳＱＬ文の中には、ヒント情報８００として、「ＷＩＴＨＯＵＴ ＸＰＡＴＨ句」が指定されている。この「ＷＩＴＨＯＵＴ ＷＰＡＴＨ句」は、共通ＸＰａｔｈ２５０を使用しないことを指示するものである。このヒント情報８００の指示により、アクセスプラン決定部１３２は、アクセスコストが最小でなくても、共通ＸＰａｔｈ２５０を使用しないアクセスプランを決定する。
【００４８】
なお、図８に示すヒント情報８００である「ＷＩＴＨ ＸＰＡＴＨ句」および「ＷＩＴＨＯＵＴ ＸＰＡＴＨ句」は、共通ＸＰａｔｈ２５０の使用可否を指定する一例であり、その他の記法で使用可否を指定することも可能である。
また、図８に示すヒント情報８００は、ＳＱＬ文単位で共通ＸＰａｔｈ２５０の使用可否をユーザが指定できるものであるが、例えば、情報処理装置５のアプリケーション処理部５５から、アプリケーション単位またはデータベース管理システム単位のヒント情報をデータベース管理部１００が取得し、ＸＭＬデータ７００の問い合わせが行なわれる際に、ヒント情報解析部１１２が、そのヒント情報に従い共通ＸＰａｔｈ２５０を用いて処理を行うか否かを判断することもできる。ここで、アプリケーション単位のヒント情報およびデータベース単位のヒント情報は、データベース管理部１００内のヒント情報解析部１１２において、共通ＸＰａｔｈ２５０の使用可否の設定を行うことができる。そして、この設定によりアクセスプラン決定部１３２は、アクセスコストが最小でなくても、共通ＸＰａｔｈ２５０を用いてアクセスプランを決定することができ、また、アクセスコストが最小でなくても、共通ＸＰａｔｈ２５０を使用しないアクセスプランを決定することができる。
【００４９】
このようにすることで、共通ＸＰａｔｈ２５０を使う必要がない場合や、共通ＸＰａｔｈ２５０を用いても、アクセスコストが低減しないことが明らかな場合において、ユーザはヒント情報８００を用いて、共通ＸＰａｔｈ２５０を使用しない処理を設定することができる。
【００５０】
図７に戻り、ステップＳ７０２において、ＳＱＬ文２００中に「共通ＸＰａｔｈ使用不可」のヒント情報８００が含まれていなかった場合（ステップＳ７０２→Ｎｏ）、ＳＱＬ分解部１１１は、入力されたＳＱＬ文２００を、選択式２０１、表式２０２、探索条件２０３に分解する（ステップＳ７０３）。「共通ＸＰａｔｈ使用」のヒント情報８００が含まれる場合、またはヒント情報自体がない場合もステップＳ７０２→Ｎｏの処理を行う。
【００５１】
次に、ＸＭＬスキーマ解析部１２１は、ＳＱＬ分解部１１１が分解した、選択式２０１、表式２０２、探索条件２０３から、処理対象となるデータの格納位置を指定するＸＰａｔｈを示す文字列を切り出す（ステップＳ７０４）。続いて、ＸＭＬスキーマ解析部１２１は、ステップＳ７０４で切り出した文字列により示されるＸＰａｔｈから、最短経路を示すＸＰａｔｈを取得する処理を行う（ステップＳ７０５）（詳細は後記する図１１〜図１２参照）。ＸＭＬスキーマ解析部１２１は、切り出した文字列が省略記法で指定されている場合には、フルパス記法に変換し、逆文書順の記法で指定されている場合には、文書順の記法に変換した上で、それぞれの文字列を補助記憶部４０に記憶されたＸＭＬスキーマ３００と突き合せる。ＸＭＬスキーマ解析部１２１は、突き合せた結果一致したＸＰａｔｈを、選択式から取得した最短経路のＸＰａｔｈ２１０、表式から取得した最短経路のＸＰａｔｈ２２０、探索条件から取得した最短経路のＸＰａｔｈ２３０としてメインメモリ１０上に保持する。なお、図７において入力されたＳＱＬ文２００（図２参照）の例においては、表式２０２にＸＰａｔｈを示す文字列がないため、ＸＭＬスキーマ解析部１２１は、表式２０２からはＸＰａｔｈを示す文字列の切り出しを行わない。
【００５２】
また、ＸＭＬスキーマ３００がない場合は、インデクス構成情報解析部１２２が、補助記憶部４０に記憶されたインデクス構成情報４００を用いて、ＸＰａｔｈの切り出しを行う（詳細は後記する図１３〜図１４参照）。
【００５３】
続いて、共通ＸＰａｔｈ抽出部１３１は、共通ＸＰａｔｈ２５０の抽出処理を行う（ステップＳ７０６）（詳細は後記する図１５参照）。共通ＸＰａｔｈ抽出部１３１は、ＸＭＬスキーマ解析部１２１またはインデクス構成情報解析部１２２の処理により取得した最短経路のＸＰａｔｈそれぞれを下位のノードからルートノードへ向かって突き合せる。そして、共通ＸＰａｔｈ抽出部１３１は、突き合せた結果、一致したＸＰａｔｈを共通ＸＰａｔｈ２５０としてメインメモリ１０上に保持する。図７の例においては、選択式から取得した最短経路のＸＰａｔｈ２１０と、探索条件から取得した最短経路のＸＰａｔｈ２３０とを突き合せ、共通ＸＰａｔｈ２５０として‘book_info/contents/chapter1’が、共通ＸＰａｔｈ抽出部１３１により抽出される。
【００５４】
図９は、図７に示した例において、共通ＸＰａｔｈ抽出部が抽出した共通ＸＰａｔｈを木構造で表現した図である。図９に示すように、共通ＸＰａｔｈ２５０として‘book_info/contents/chapter1’が、ルートノードである「book_info」から「chapter1」までのパスとして、共通ＸＰａｔｈ抽出部１３１により抽出される。
【００５５】
図７に戻り、アクセスプラン決定部１３２は、アクセスプラン決定処理を行う（ステップＳ７０７）（詳細は後記する図１６参照）。ここでアクセスプラン決定部１３２は、抽出した共通ＸＰａｔｈ２５０を使用するアクセスプランと、共通ＸＰａｔｈ２５０を使用しないアクセスプランとを比較し、アクセスコストが最小となるアクセスプランを決定する。
【００５６】
図１０は、共通ＸＰａｔｈを使用してアクセスコストの合計値を算出したアクセスプランと、共通ＸＰａｔｈを使用しないでアクセスコストの合計値を算出したアクセスプランとを、比較した例を示す図である。アクセスプラン決定部１３２は、図５に示したアクセスコスト設定情報５００で設定された各処理ごとのアクセスコストに基づき、共通ＸＰａｔｈ２５０を使用した場合のアクセスコストの合計値と、共通ＸＰａｔｈ２５０を使用しない場合のアクセスコストの合計値とを算出する。図１０に示す例においては、共通ＸＰａｔｈ２５０を使用する場合（プラン１）のアクセスコストの合計値は「３５３０」であり、共通ＸＰａｔｈ２５０を使用しない場合（プラン２）のアクセスコストの合計値は「４０１０」であるため、アクセスプラン決定部１３２は、アクセスコストが最小となる方である共通ＸＰａｔｈ２５０を使用するアクセスプラン（プラン１）に、アクセスプランを決定する。
【００５７】
図７に戻り、アクセスプラン決定部１３２により決定されたアクセスプランに基づき、ＳＱＬ実行部１４０は、アクセスプランの実行処理を行う（ステップＳ７０８）（詳細は後記する図１７〜図２０参照）。
【００５８】
（最短経路を示すＸＰａｔｈ取得処理）
次に、ＸＭＬスキーマ解析部１２１による最短経路を示すＸＰａｔｈの取得処理について詳細に説明する。なお、図７に示すステップにおいては、ステップＳ７０４およびステップＳ７０５の処理に該当する。
【００５９】
図１１および図１２は、図１に示すＸＭＬスキーマ解析部が、切り出された選択式、表式および探索条件それぞれから、最短経路を示すＸＰａｔｈの取得する際の流れを示すフローチャートである。
【００６０】
図１１に示すように、まず、ＸＭＬスキーマ解析部１２１は、補助記憶部４０（図１参照）にＸＭＬスキーマ３００があるか否か判定する（ステップＳ１１０１）。ＸＭＬスキーマ３００があれば（ステップＳ１１０１→Ｙｅｓ）、ＸＭＬスキーマ解析部１２１は、探索条件２０３からＸＰａｔｈを示す文字列を切り出す（ステップＳ１１１０）。次に、ＸＭＬスキーマ解析部１２１は、切り出した文字列が省略記法の場合、フルパスの記法に変換する（ステップＳ１１１１）。続いてＸＭＬスキーマ解析部１２１は、切り出した文字列が逆文書順の記法の場合、文書順の記法に変換する（ステップＳ１１１２）。そしてＸＭＬスキーマ解析部１２１は、変換したＸＰａｔｈとＸＭＬスキーマ３００とをルートノードから文書順に突き合せる（ステップＳ１１１３）。続いてＸＭＬスキーマ解析部１２１は、突き合せで一致したＸＰａｔｈを探索条件から取得した最短経路のＸＰａｔｈ２３０としてメインメモリ１０上に保持する（ステップＳ１１１４）。次に、ＸＭＬスキーマ解析部１２１は、探索条件２０３中のＸＰａｔｈの全てを突き合せたか否かを判断する（ステップＳ１１１５）。まだ突き合せていないＸＰａｔｈがある場合には（ステップＳ１１１５→Ｎｏ）、ステップＳ１１１０に戻り処理を続ける。一方、探索条件２０３中のＸＰａｔｈの全てを突き合せた場合には（ステップＳ１１１５→Ｙｅｓ）、ステップＳ１１１６の処理へ進む。そして、ＸＭＬスキーマ解析部１２１は、探索条件から取得した最短経路のＸＰａｔｈ２３０のうち、重複しているＸＰａｔｈがあれば、メインメモリ１０上から削除する（ステップＳ１１１６）。なお、ステップＳ１１０１において、補助記憶部４０にＸＭＬスキーマ３００がなければ（ステップＳ１１０１→Ｎｏ）、後記する図１３のインデクス構成情報解析部１２２によるステップＳ１３０１へ進む。
【００６１】
次にＸＭＬスキーマ解析部１２１は、選択式２０１からＸＰａｔｈを示す文字列を切り出す（ステップＳ１１２０）。そして、ＸＭＬスキーマ解析部１２１は、選択式２０１から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１１１１〜Ｓ１１１６までの処理と同様の処理（ステップＳ１１２１〜Ｓ１１２６）を行って、突き合せで一致したＸＰａｔｈを選択式から取得した最短経路のＸＰａｔｈ２１０としてメインメモリ１０上に保持する。
【００６２】
続いて、ＸＭＬスキーマ解析部１２１は、図１２のステップＳ１１３０に進み、表式２０２からＸＰａｔｈを示す文字列を切り出す。ＸＭＬスキーマ解析部１２１は、表式２０２から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１１１１〜Ｓ１１１６までの処理と同様の処理（ステップＳ１１３１〜Ｓ１１３６）を行って、突き合せで一致したＸＰａｔｈを表式から取得した最短経路のＸＰａｔｈ２２０としてメインメモリ１０上に保持する。
【００６３】
また、補助記憶部４０にインデクス構成情報４００が記憶されている場合、インデクス構成情報解析部１２２は、インデクス構成情報４００を用いて、最短経路を示すＸＰａｔｈを取得する処理を行う。図１３および図１４は、インデクス構成情報解析部が、切り出された選択式、表式および探索条件それぞれから、最短経路を示すＸＰａｔｈを取得する際の流れを示すフローチャートである。
【００６４】
まず、インデクス構成情報解析部１２２は、補助記憶部４０（図１参照）にインデクス構成情報４００があるか否かを判定する（ステップＳ１３０１）。インデクス構成情報４００があれば（ステップＳ１３０１→Ｙｅｓ）、インデクス構成情報解析部１２２は、探索条件２０３からＸＰａｔｈを示す文字列を切り出す（ステップＳ１３１０）。次に、インデクス構成情報解析部１２２は、切り出した文字列が省略記法の場合、フルパスの記法に変換する（ステップＳ１３１１）。続いてインデクス構成情報解析部１１２は、切り出した文字列が逆文書順の記法の場合、文書順の記法に変換する（ステップＳ１３１２）。そしてインデクス構成情報解析部１２２は、変換したＸＰａｔｈとインデクス構成情報４００とをルートノードから文書順に突き合せる（ステップＳ１３１３）。続いてインデクス構成情報解析部１２２は、突き合せで一致したＸＰａｔｈを探索条件から取得した最短経路のＸＰａｔｈ２３０としてメインメモリ１０上に保持する（ステップＳ１３１４）。次に、インデクス構成情報解析部１２２は、探索条件２０３中のＸＰａｔｈの全てを突き合せたか否かを判断する（ステップＳ１３１５）。まだ突き合せていないＸＰａｔｈがある場合には（ステップＳ１３１５→Ｎｏ）、ステップＳ１３１０に戻り処理を続ける。一方、探索条件２０３中のＸＰａｔｈの全てを突き合せた場合には（ステップＳ１３１５→Ｙｅｓ）、ステップＳ１３１６の処理へ進む。そして、インデクス構成情報解析部１２２は、探索条件から取得した最短経路のＸＰａｔｈ２３０のうち、重複しているＸＰａｔｈがあれば、メインメモリ１０上から削除する（ステップＳ１３１６）。なお、ステップＳ１３０１において、補助記憶部４０にインデクス構成情報４００がなければ（ステップＳ１３０１→Ｎｏ）、処理を終える。
【００６５】
次にインデクス構成情報解析部１２２は、選択式２０１からＸＰａｔｈを示す文字列を切り出す（ステップＳ１３２０）。そして、インデクス構成情報解析部１２２は、選択式２０１から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１３１１〜Ｓ１３１６までの処理と同様の処理（ステップＳ１３２１〜Ｓ１３２６）を行って、突き合せで一致したＸＰａｔｈを選択式から取得した最短経路のＸＰａｔｈ２１０としてメインメモリ１０上に保持する。
【００６６】
続いて、インデクス構成情報解析部１１２は、図１４のステップＳ１３３０に進み、表式２０２からＸＰａｔｈを示す文字列を切り出す。インデクス構成情報解析部１２２は、表式２０２から切り出したＸＰａｔｈを示す文字列について、探索条件２０３におけるステップＳ１３１１〜Ｓ１３１６までの処理と同様の処理（ステップＳ１３３１〜Ｓ１３３６）を行って、突き合せで一致したＸＰａｔｈを表式から取得した最短経路のＸＰａｔｈ２２０としてメインメモリ１０上に保持する。
【００６７】
（共通ＸＰａｔｈ抽出処理）
次に、図７のステップＳ７０６の処理である、共通ＸＰａｔｈ抽出部１３１が共通ＸＰａｔｈ２５０を抽出する流れを具体的に説明する。図１５は、共通ＸＰａｔｈ抽出部が共通ＸＰａｔｈを抽出する流れを示すフローチャートである。
【００６８】
図１５に示すように、まず、共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した探索条件から取得した最短経路のＸＰａｔｈ２３０があるか否か判定する（ステップＳ１５０１）。共通ＸＰａｔｈ抽出部１３１は、探索条件から取得した最短経路のＸＰａｔｈ２３０があれば（ステップＳ１５０１→Ｙｅｓ）、探索条件から取得した最短経路のＸＰａｔｈ２３０を読み込む（ステップＳ１５０２）。探索条件から取得した最短経路のＸＰａｔｈ２３０がなければ（ステップＳ１５０１→Ｎｏ）、探索条件２０３からＸＰａｔｈを示す文字列を、探索条件から取得した最短経路のＸＰａｔｈ２３０として切り出す（ステップＳ１５０３）。
【００６９】
次に、共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した選択式から取得した最短経路のＸＰａｔｈ２１０があるか否か判定する（ステップＳ１５０４）。選択式から取得した最短経路のＸＰａｔｈ２１０があれば（ステップＳ１５０４→Ｙｅｓ）、共通ＸＰａｔｈ抽出部１３１は、選択式から取得した最短経路のＸＰａｔｈ２１０を読み込む（ステップＳ１５０５）。選択式から取得した最短経路のＸＰａｔｈ２１０がなければ（ステップＳ１５０４→Ｎｏ）、選択式２０１からＸＰａｔｈを示す文字列を、選択式から取得した最短経路のＸＰａｔｈ２１０として切り出す（ステップＳ１５０６）。
【００７０】
続いて、共通ＸＰａｔｈ抽出部１３１は、メインメモリ１０上に保持した表式から取得した最短経路のＸＰａｔｈ２２０があるか否かを判定する（ステップＳ１５０７）。表式から取得した最短経路のＸＰａｔｈ２２０があれば（ステップＳ１５０７→Ｙｅｓ）、共通ＸＰａｔｈ抽出部１３１は、表式から取得した最短経路のＸＰａｔｈ２２０を読み込む（ステップＳ１５０８）。表式から取得した最短経路のＸＰａｔｈ２２０がなければ（ステップＳ１５０７→Ｎｏ）、表式２０２からＸＰａｔｈを示す文字列を、表式から取得した最短経路のＸＰａｔｈ２２０として切り出す（ステップＳ１５０９）。
【００７１】
なお、共通ＸＰａｔｈ抽出部１３１が行うステップＳ１５０３、ステップＳ１５０６およびステップＳ１５０９における、探索条件２０１、選択式２０２および表式２０３からＸＰａｔｈを示す文字列を切り出す処理は、補助記憶部４０に、ＸＭＬスキーマ３００およびインデクス構成情報４００が記憶されていない場合に行われる処理である。ただし、このステップＳ１５０３、ステップＳ１５０６およびステップＳ１５０９における処理は、共通ＸＰａｔｈ抽出部１３１に予め設定することにより、これらのステップを行わないことも可能である。その場合、例えば、共通ＸＰａｔｈ抽出部１３１は、ステップＳ１５０１において、メインメモリ１０上に保持した探索条件から取得した最短経路のＸＰａｔｈ２１０がなければ（ステップＳ１５０１→Ｎｏ）、探索条件から取得したＸＰａｔｈの読み込みを行わず、次のステップＳ１５０４へ進む。同様に、選択式からＸＰａｔｈを示す文字列を最短経路の文字列として切り出すステップＳ１５０６が設定されていない場合には、次のステップＳ１５０７へ進む。また、表式からＸＰａｔｈを示す文字列を最短経路の文字列として切り出すステップＳ１５０９が設定されていない場合には、次のステップＳ１５１０へ進む。
【００７２】
次に、共通ＸＰａｔｈ抽出部１３１は、読み込んだ探索条件から取得したＸＰａｔｈ２３０、選択式から取得したＸＰａｔｈ２１０および表式から取得したＸＰａｔｈ２２０それぞれを、下位ノードからルートノードへ向かって突き合せる（ステップＳ１５１０）。そして、共通ＸＰａｔｈ抽出部１３１は、一致したＸＰａｔｈを共通ＸＰａｔｈ２５０としてメインメモリ１０上に保持する（ステップＳ１５１１）。続いて共通ＸＰａｔｈ抽出部１３１は、最短経路のＸＰａｔｈの全てを突き合せたか否かを判断する（ステップＳ１５１２）。そして、突き合せていない最短経路のＸＰａｔｈがある場合には（ステップＳ１５１２→Ｎｏ）、ステップＳ１５１０に戻り処理を続ける。一方、全てのＸＰａｔｈの突き合せが終わっている場合には（ステップＳ１５１２→Ｙｅｓ）、ステップＳ１５１３へ進み、抽出した共通ＸＰａｔｈ２５０のうち、重複している共通ＸＰａｔｈ２５０をメインメモリ１０から削除する。
【００７３】
なお、この共通ＸＰａｔｈ２５０は一度処理したパスの評価を複数回行わないために使用する。従って、表式から取得した共通ＸＰａｔｈ２５０は、表式の評価後に行う探索条件または選択式の処理で使用する（詳細は図１９、図２０で説明する）。探索条件から取得した共通ＸＰａｔｈ２５０は、探索条件評価後に行う選択式の評価で使用する（詳細は図２０で説明する）。
【００７４】
（ＸＰａｔｈの文字列比較）
ここまでは、ＸＭＬスキーマ３００またはインデクス構成情報４００を用いて共通ＸＰａｔｈ２５０を取得する場合を述べた。しかし、ＸＭＬスキーマ３００、インデクス構成情報４００がない場合は、ＳＱＬ文中からＸＰａｔｈを示す文字列を切り出し、文字列比較を行うことにより共通ＸＰａｔｈ２５０を取得することも可能である。
【００７５】
（アクセスプラン決定処理）
次に、図７のステップＳ７０７に示すアクセスプラン決定処理について具体的に説明する。図１６はアクセスプラン決定部が共通ＸＰａｔｈを利用したアクセスプランを決定する際の流れを示したフローチャートである。アクセスプラン決定部１３２は共通ＸＰａｔｈ２５０およびＳＱＬ文２００を分解した選択式２０１、表式２０２、探索条件２０３を取得とする。なお、ここでは表式の評価、探索条件評価、行ＩＤ返却、共通ＸＰａｔｈ２５０が示すデータ格納位置情報返却、行ＩＤに基づきデータ取得、データ格納位置情報６００に基づき共通ＸＰａｔｈ２５０が示すノード以下のデータ取得、および選択式のＸＰａｔｈ評価を行う手順をアクセスプランとする。
【００７６】
図１６に示すように、まず、アクセスプラン決定部１３２は、表式を評価するアクセスコストを計算し（ステップＳ１６０１）、探索条件を評価するアクセスコストを計算し（ステップＳ１６０２）、選択式を評価するアクセスコストを計算する（ステップＳ１６０３）。そして、アクセスプラン決定部１３２は、ステップＳ１６０１〜Ｓ１６０３で求めた全アクセスコストを合計し、アクセスプラン全体のアクセスコストを計算する（ステップＳ１６０４）。
【００７７】
次に、アクセスプラン決定部１３２は、メインメモリ１０上に保持した共通ＸＰａｔｈ２５０があるか否かを判定する（ステップＳ１６０５）。共通ＸＰａｔｈ２５０があれば（ステップＳ１６０５→Ｙｅｓ）、アクセスプラン決定部１３２は、共通ＸＰａｔｈ２５０を読み出す（ステップＳ１６０６）。続いて、アクセスプラン決定部１３２は、共通ＸＰａｔｈ２５０に含まれるノード数をカウントする（ステップＳ１６０７）。そして、アクセスプラン決定部１３２は、選択式および探索条件の評価時に評価を省略できるノード数に応じたアクセスコストを計算する（ステップＳ１６０８）。続いて、アクセスプラン決定部１３２は、共通ＸＰａｔｈ２５０が示すデータ格納位置情報を取得するアクセスコストを計算する（ステップＳ１６０９）。次に、アクセスプラン決定部１３２は、共通ＸＰａｔｈが示すデータを取得するアクセスコストを計算する（ステップＳ１６１０）。続いて、アクセスプラン決定部１３２は、表式を評価するアクセスコストを計算し（ステップＳ１６１１）、探索条件を評価するアクセスコストを計算し（ステップＳ１６１２）、選択式を評価するアクセスコストを計算する（ステップＳ１６１３）。
【００７８】
次に、アクセスプラン決定部１３２は、ステップＳ１６０８〜ステップＳ１６１３で求めた全アクセスコストを合計し、アクセスプラン全体のアクセスコストを計算する（ステップＳ１６１４）。続いて、アクセスプラン決定部１３２は、全ての共通ＸＰａｔｈ２５０についてステップＳ１６０７〜Ｓ１６１４までの処理を行ったか否かを判断する（ステップＳ１６１５）。まだ処理していない共通ＸＰａｔｈ２５０がある場合には（ステップＳ１６１５→Ｎｏ）、ステップ１６０７に戻り処理を続ける。一方、全ての共通ＸＰａｔｈについてのアクセスコストが計算済みであれば（ステップＳ１６１５→Ｙｅｓ）、次のステップＳ１６１６へ進む。
【００７９】
一方、ステップＳ１６０５において、メインメモリ１０上に保持した共通ＸＰａｔｈ２５０がない場合は（ステップＳ１６０５→Ｎｏ）、次のステップＳ１６１６へ進む。次に、アクセスプラン決定部１３２は、ステップＳ１６０４およびステップＳ１６１４で算出したアクセスプランそれぞれのアクセスコストの内、アクセスコストが最小のものをアクセスプランとして決定する（ステップＳ１６１６）。そして、アクセスプラン決定部１３２は、決定したアクセスプランを、インタプリタが実行できる中間コードに変換する（ステップＳ１６１７）。
【００８０】
図１０のアクセスコストを比較した例を用いて、具体的に説明する。アクセスプラン決定部１３２は、例えば、図５で定められたアクセスコストをもとに計算するものとする。図１０に示すように、共通ＸＰａｔｈ２５０を使用してアクセスプランを設定する場合（プラン１）、アクセスプラン決定部１３２は、探索条件のＸＰａｔｈ評価「２０００」、行ＩＤ返却「１０」、共通ＸＰａｔｈ２５０が示すノードのデータ格納位置情報返却「１０」、行ＩＤからデータ取得「１０００」、データ格納位置情報を用いて共通ＸＰａｔｈ２５０が示すノード以降のデータ取得「１０」、共通ＸＰａｔｈ２５０が示すノード以降の選択式のＸＰａｔｈ評価「５００」を行うので、全体のアクセスコストは全てを合算して「３５３０」と算出する。一方、共通ＸＰａｔｈ２５０を使用しない場合（プラン２）、アクセスプラン決定部１３２は、探索条件のＸＰａｔｈ評価「２０００」、行ＩＤ返却「１０」、行ＩＤからのデータ取得「１０００」、ルートノード以降の選択式のＸＰａｔｈ評価「１０００」を行うので、全体のアクセスコストは全てを合算して「４０１０」となる。アクセスプラン決定部１３２は、このように、共通ＸＰａｔｈ２５０を用いたアクセスプランのアクセスコストの合計値と、共通ＸＰａｔｈ２５０を使用しないアクセスプランのアクセスコストの合計値とを比較した上で、アクセスコストの合計値が最小のものアクセスプランとして決定する。
【００８１】
（アクセスプラン実行処理）
図７のステップＳ７０８に示すアクセスプラン実行処理について具体的に説明する。
図１７は、図１に示すアクセスプラン決定部で決定したアクセスプランに基づいて、ＳＱＬ実行部がＳＱＬ文の処理を実行する全体の処理の流れを示す概念図である。なお、図１７（ａ）は、データベースアクセス部、探索条件評価部、選択式実行部が行う処理の流れを示すフローチャートである。また、図１７（ｂ）は、図１７（ａ）に対応した実際のデータに基づいた処理を説明するための概念図である。なお、ここでは図２に示すＳＱＬ文２００がデータベース管理装置１に入力され、共通ＸＰａｔｈ２５０として、‘book_info/contents/chapter1’が抽出された場合として説明する。
【００８２】
図１７（ａ）に示すように、まずデータベースアクセス部１４１（図１参照）は、補助記憶装置４０に記憶されているＸＭＬデータ７００のうち、表（ＢＯＯＫ＿ＴＢＬ）にアクセスする（ステップＳ１７０１）。次に、探索条件評価部１４２は、探索条件の評価を行う（ステップＳ１７０２）。そして、探索条件の評価が真となった行の行ＩＤ６２０（＃１，＃３，…）を取得し（ステップＳ１７０３）、共通ＸＰａｔｈ２５０が示すノードの位置情報６３０を取得する（ステップＳ１７０４）。そして、取得した行ＩＤ６２０と位置情報６３０とを示すデータ格納位置情報６００をメインメモリ１０上に保持する。
【００８３】
次に、選択式実行部１４３は、データ格納位置情報６００に格納されている行ＩＤ６２０からデータを取得し（ステップＳ１７０５）、メインメモリ１０上に展開する。そして、選択式実行部１４３は、データ格納位置情報６００に格納されている位置情報６３０を用いて、メインメモリ１０上に展開されているデータから、共通ＸＰａｔｈ２５０が示すノード以降のデータを取得する処理を行う（ステップＳ１７０６）。そして、選択式実行部１４３は、ルートノードから共通ＸＰａｔｈ２５０が示すノードまでの評価を行わず、選択式のＸＰａｔｈを共通ＸＰａｔｈ２５０で示すノード以降のデータに対して評価する（ステップＳ１７０７）。
【００８４】
次に、アクセスプラン実行処理において、データベースアクセス部１４１、探索条件評価部１４２、選択式実行部１４３のそれぞれが行う詳細な処理の流れを具体的に説明する。
【００８５】
（データベースアクセス処理）
図１８は、アクセスプランに基づき、図１のデータベースアクセス部がデータベースにアクセスする際の流れを示したフローチャートである。データベースアクセス部１４１には、アクセスプラン決定部１３２が作成した中間コードが入力される。
【００８６】
図１８に示すように、まずデータベースアクセス部１４１は、表式２０２に示される表にアクセスする（ステップＳ１８０１）。次に、データベースアクセス部１４１は、表式に含まれるＸＰａｔｈを評価する（ステップＳ１８０２）。そして、データベースアクセス部１４１は、共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があるか否かを判定する（ステップＳ１８０３）。共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があれば（ステップＳ１８０３→Ｙｅｓ）、データベースアクセス部１４１は、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００を取得し、メインメモリ１０上に保持する（ステップＳ１８０４）。一方、データ格納位置情報６００の取得指示がなければ（ステップＳ１８０３→Ｎｏ）、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００を取得せず、ステップＳ１８０５へ進む。そして、データベースアクセス部１４１は、表式２０２中の全てのＸＰａｔｈを評価したか否かを判断する（ステップＳ１８０５）。表式２０２中のＸＰａｔｈにおいて評価していないＸＰａｔｈがあれば（ステップＳ１８０５→Ｎｏ）、ステップＳ１８０２に戻り処理を続ける。表式２０２中の全てのＸＰａｔｈを評価していれば（ステップＳ１８０５→Ｙｅｓ）、データベースアクセス部１４０での処理を終える。なお、表式２０２中にＸＰａｔｈがない場合は、データベースアクセス部１４１は、ステップＳ１８０１のみを行う。
【００８７】
データベースアクセス部１４１がステップＳ１８０４において取得する共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００は、探索条件評価部１４２または選択式実行部１４３で使用する。また、探索条件評価部１４２が取得する共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００（後記する図１９のステップＳ１９０７またはステップＳ１９１１）は、選択式実行部１４３で使用する。探索条件評価部１４２と選択式実行部１４３で使用するデータ格納位置情報６００は同じである必要はなく、アクセスコストが最小となるようにアクセスプラン決定部１３２により決定される。
【００８８】
（探索条件評価処理）
図１９は、アクセスプランに基づき、図１の探索条件評価部が探索条件を評価する際の流れを示したフローチャートである。探索条件評価部１４２は、データベースアクセス部１４１がアクセスしたデータ、およびメインメモリ１０上に保持したデータ格納位置情報６００が入力されている。
【００８９】
図１９に示すように、まず探索条件評価部１４２は、データベースアクセス部１４１で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００（図６参照）があるか否かを判定する（ステップＳ１９０１）。ここで、データ格納位置情報６００がある場合（ステップＳ１９０１→Ｙｅｓ）とは、表式にＸＰａｔｈを含み、そのＸＰａｔｈと探索条件のＸＰａｔｈから共通ＸＰａｔｈ２５０が抽出できる場合である。ただし、共通ＸＰａｔｈ２５０を抽出しても、アクセスコストが最小にならなければ、データ格納位置情報６００を取得しないアクセスプランとなることがある。
【００９０】
探索条件評価部１４２は、データ格納位置情報６００があれば（ステップＳ１９０１→Ｙｅｓ）、次にデータ格納位置情報６００に子孫ノード情報６４０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ１９０２）。そして、子孫ノード情報６４０が設定されていない場合は（ステップＳ１９０２→Ｎｏ）、ステップＳ１９０４へ進む。一方、子孫ノード情報６４０が設定されている場合には（ステップＳ１９０２→Ｙｅｓ）、ステップＳ１９０３へ進み、子孫ノード情報６４０に基づき、子孫ノードが存在するか否かを判断する（ステップＳ１９０３）。ここで、子孫ノード情報６４０により子孫ノードが存在しないと判断した場合は（ステップＳ１９０３→Ｎｏ）、データの読み込みを行わずステップＳ１９０８へ進む。一方、子孫ノード情報６４０により子孫ノードが存在すると判断した場合には（ステップＳ１９０３→Ｙｅｓ）、ステップＳ１９０４へ進む。
【００９１】
このように、子孫ノード情報６４０をデータ格納位置情報６００として設定することにより、子孫ノード情報６４０で子孫ノードが存在しない場合は（ステップＳ１９０３→Ｎｏ）、探索条件の処理において、共通ＸＰａｔｈ２５０で指定されたノード以降の子孫ノードのデータを読み込まないため、探索時間を短縮することができる。
【００９２】
次に、探索条件評価部１４２は、データ格納位置情報６００にノードテスト情報６５０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ１９０４）。そして、ノードテスト情報６５０が設定されていない場合には（ステップＳ１９０４→Ｎｏ）、ステップＳ１９０６へ進む。一方、ノードテスト情報６５０が設定されている場合には（ステップＳ１９０４→Ｙｅｓ）、ステップＳ１９０５へ進み、ノードテスト情報６５０に基づき、ノードテストに合致するか否かを判断する（ステップＳ１９０５）。ここで、ノードテスト情報６５０によりノードテストに合致しないと判断された場合は（ステップＳ１９０５→Ｎｏ）、データの読み込みを行わずステップＳ１９０８へ進む。一方、ノードテスト情報６５０により、ノードテストに合致すると判断された場合には（ステップＳ１９０５→Ｙｅｓ）、ステップＳ１９０６の処理へ進む。
【００９３】
このように、ノードテスト情報６５０をデータ格納位置情報６００として設定することにより、共通ＸＰａｔｈ２５０が示すノードがノードテスト６５０に合致しない場合は（ステップＳ１９０５→Ｎｏ）、探索条件の処理において、そのノードが示すデータを読み込まないため、探索時間を短縮することができる。
【００９４】
次に、ステップＳ１９０６において、探索条件評価部１４２は、データ格納位置情報６００から共通ＸＰａｔｈ２５０が示すノード以降のデータを読み込む（ステップＳ１９０６）。そして、読み込んだデータを用いて、探索条件評価部１４２が探索条件を評価する（ステップＳ１９０７）。続いて、探索条件評価部１４２は、共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があるか否かを判定する（ステップＳ１９０８）。データ格納位置情報６００の取得指示があれば（ステップＳ１９０８→Ｙｅｓ）、探索条件評価部１４２は、データ格納位置情報６００を取得し、メインメモリ１０上に保持する（ステップＳ１９０９）。一方、データ格納位置情報６００の取得指示がなければ（ステップＳ１９０８→Ｎｏ）、ステップＳ１９１０へ進む。続いて、探索条件評価部１４２は、全ての探索条件を評価したか否かを判断する（ステップＳ１９１０）。そして、評価していない探索条件がある場合には（ステップＳ１９１０→Ｎｏ）、ステップＳ１９０２へ戻り処理を続ける。一方、全ての探索条件を評価していれば（ステップＳ１９１０→Ｙｅｓ）、処理を終える。
【００９５】
一方、ステップＳ１９０１において、データベースアクセス部１４１で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００がなければ（ステップＳ１９０１→Ｎｏ）、探索条件評価部１４２は、共通ＸＰａｔｈ２５０を用いずに、探索条件の評価を行う（ステップＳ１９１１）。次に、探索条件評価部１４２は、共通ＸＰａｔｈ２５０によるデータ格納位置情報６００の取得指示があるか否かを判定する（ステップＳ１９１２）。データ格納位置情報６００の取得指示があれば（ステップＳ１９１２→Ｙｅｓ）、探索条件評価部１４２は、データ格納位置情報６００を取得し、メインメモリ１０上に保持する（ステップＳ１９１３）。一方、データ格納位置情報６００の取得指示がなければ（ステップＳ１９１２→Ｎｏ）、ステップＳ１９１４へ進む。続いて、探索条件評価部１４２は、全ての探索条件を評価したか否かを判断する（ステップＳ１９１４）。そして、評価していない探索条件がある場合には（ステップＳ１９１４→Ｎｏ）、ステップＳ１９１１へ戻り処理を続ける。一方、全ての探索条件を評価していれば（ステップＳ１９１４→Ｙｅｓ）、処理を終える。
【００９６】
（選択式評価処理）
図２０はアクセスプランに基づき、図１の選択式実行部が選択式のＸＰａｔｈを評価する際の流れを示すフローチャートである。選択式実行部１４３は、データベースアクセス部１４１または探索条件評価部１４２でメインメモリ７００上に保持したデータ格納位置情報６００が入力されている。
【００９７】
図２０に示すように、まず選択式実行部１４３は、データベースアクセス部１４１または探索条件評価部１４２で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００があるか否かを判定する（ステップＳ２００１）。
【００９８】
ここで、データ格納位置情報６００がある場合（ステップＳ２００１→Ｙｅｓ）とは、次の３つの場合がある。（１） 表式２０２にＸＰａｔｈを含み、そのＸＰａｔｈと選択式２０１のＸＰａｔｈとから共通ＸＰａｔｈ２５０が抽出できる場合。（２）探索条件２０３にＸＰａｔｈを含み、そのＸＰａｔｈと選択式２０１のＸＰａｔｈとから共通ＸＰａｔｈ２５０が抽出できる場合。（３）表式２０２にＸＰａｔｈを含み、探索条件２０３にもＸＰａｔｈを含み、それらのＸＰａｔｈと選択式２０１のＸＰａｔｈとから共通ＸＰａｔｈ２５０が抽出できる場合である。この３つの場合の中で、どの共通ＸＰａｔｈ２５０を使用するかは、アクセスプラン決定部１３２により決定されたアクセスプランに基づく。従って、共通ＸＰａｔｈ２５０を抽出しても、アクセスコストが最小にならなければ、データ格納位置情報６００を取得しないアクセスプランとなることがある。
【００９９】
図２０に戻り、選択式実行部１４３は、共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００があれば（ステップＳ２００１→Ｙｅｓ）、次にデータ格納位置情報６００に子孫ノード情報６４０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ２００２）。そして、子孫ノード情報６４０が設定されていない場合は（ステップＳ２００２→Ｎｏ）、ステップＳ２００４へ進む。一方、子孫ノード情報６４０が設定されている場合には（ステップＳ２００２→Ｙｅｓ）、ステップＳ２００３へ進み、子孫ノード情報６４０に基づき、子孫ノードが存在するか否かを判断する（ステップＳ２００３）。ここで、子孫ノード情報６４０により子孫ノードが存在しないと判断した場合は（ステップＳ２００３→Ｎｏ）、データの読み込みを行わずステップＳ２００８へ進む。一方、子孫ノード情報６４０により子孫ノードが存在すると判断した場合には（ステップＳ２００３→Ｙｅｓ）、ステップＳ２００４へ進む。
【０１００】
このように、子孫ノード情報６４０をデータ格納位置情報６００として設定することにより、子孫ノード情報６４０で子孫ノードが存在しない場合は（ステップＳ２００３→Ｎｏ）、選択式の処理において、共通ＸＰａｔｈ２５０で指定されたノード以降の子孫ノードのデータを読み込まないため、探索時間を短縮することができる。
【０１０１】
次に、選択式実行部１４３は、データ格納位置情報６００にノードテスト情報６５０（図６（ｂ）参照）が設定されているか否かを判断する（ステップＳ２００４）。そして、ノードテスト情報６５０が設定されていない場合には（ステップＳ２００４→Ｎｏ）、ステップＳ２００６へ進む。一方、ノードテスト情報６５０が設定されている場合には（ステップＳ２００４→Ｙｅｓ）、ステップＳ２００５へ進み、ノードテスト情報６５０に基づき、ノードテストに合致するか否かを判断する（ステップＳ２００５）。ここで、ノードテスト情報６５０によりノードテストに合致しないと判断された場合は（ステップＳ２００５→Ｎｏ）、データの読み込みを行わずステップＳ２００８へ進む。一方、ノードテスト情報６５０により、ノードテストに合致すると判断された場合には（ステップＳ２００５→Ｙｅｓ）、ステップＳ２００６の処理へ進む。
【０１０２】
このように、ノードテスト情報６５０をデータ格納位置情報６００として設定することにより、共通ＸＰａｔｈ２５０が示すノードがノードテスト６５０に合致しない場合は（ステップＳ２００５→Ｎｏ）、選択式の処理において、そのノードが示すデータを読み込まないため、探索時間を短縮することができる。
【０１０３】
次に、ステップＳ２００６において、選択式実行部１４３は、データ格納位置情報６００から共通ＸＰａｔｈ２５０が示すノード以降のデータを読み込む（ステップＳ２００６）。次に、読み込んだデータを用いて選択式実行部１４３は、共通ＸＰａｔｈ２５０が示すノード以降の選択式のＸＰａｔｈを評価する（ステップＳ２００７）。続いて、選択式実行部１４３は、全ての選択式を評価したか否かを判断する（ステップＳ２００８）。そして、評価していない選択式がある場合には（ステップＳ２００８→Ｎｏ）、ステップＳ２００２へ戻り処理を続ける。一方、全ての選択式を評価していれば（ステップＳ２００８→Ｙｅｓ）、処理を終える。
【０１０４】
一方、ステップＳ２００１において、データベースアクセス部１４１または探索条件評価部１４２で取得した共通ＸＰａｔｈ２５０が示すデータ格納位置情報６００がなければ（ステップＳ２００１→Ｎｏ）、選択式実行部１４３は、補助記憶部４０からＸＭＬデータ７００を読み込む（ステップＳ２００９）。続いて、選択式実行部１４３は、読み込んだデータを用いて選択式のＸＰａｔｈを評価する（ステップＳ２０１０）。次に、選択式実行部１４３は、全ての選択式を評価したか否かを判断する（ステップＳ２０１１）。そして、評価していない選択式がある場合には（ステップＳ２０１１→Ｎｏ）、ステップＳ２０１０へ戻り処理を続ける。一方、全ての選択式を評価していれば（ステップＳ２０１１→Ｙｅｓ）、処理を終える。
【０１０５】
このようにすることで、本実施形態に係るデータベース管理方法、データベース管理装置およびプログラムは、ルートノードから共通パスに示されるノードまで辿る処理を排除し、構造化データの検索時間を短縮することができる。
【図面の簡単な説明】
【０１０６】
【図１】本実施形態に係るデータベース管理システムの構成を示す機能ブロック図である。
【図２】実施形態に係るデータベース管理装置に入力されるＳＱＬの一例を示す図である。
【図３】本実施形態に係るＸＭＬスキーマの一例を示す図である。
【図４】本実施形態に係るインデクス構成情報の一例を示す図である。
【図５】本実施形態に係るアクセスコスト設定情報の一例を示す図である。
【図６】本実施形態に係るデータ格納位置情報の一例を示す図である。
【図７】本実施形態に係るデータベース管理方法の処理の流れを示すフローチャートである。
【図８】本実施形態に係るデータベース管理装置に入力されるＳＱＬ文中にヒント情報が含まれている例を示す図である。
【図９】本実施形態に係る共通ＸＰａｔｈを木構造で表現した図である。
【図１０】本実施形態に係るデータベース管理方法においてアクセスコストが最小のアクセスプランの決定を説明するための図である。
【図１１】本実施形態に係るデータベース管理方法において、ＸＭＬスキーマを用いて、探索条件および選択式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１２】本実施形態に係るデータベース管理方法において、ＸＭＬスキーマを用いて、表式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１３】本実施形態に係るデータベース管理方法において、インデクス構成情報を用いて、探索条件および選択式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１４】本実施形態に係るデータベース管理装置において、インデクス構成情報を用いて、表式中のＸＰａｔｈの処理の流れを示すフローチャートである。
【図１５】本実施形態に係るデータベース管理方法において、共通ＸＰａｔｈを抽出する処理の流れを示すフローチャートである。
【図１６】本実施形態に係るデータベース管理方法において、共通ＸＰａｔｈを利用したアクセスプランを決定する際の流れを示すフローチャートである。
【図１７】本実施形態に係るデータベース管理方法において、アクセスプランに従い、ＳＱＬを実行する概念を説明するための図である。
【図１８】本実施形態に係るデータベース管理方法において、データベースにアクセスする際の流れを示したフローチャートである。
【図１９】本実施形態に係るデータベース管理方法において、探索条件を評価する際の流れを示したフローチャートである。
【図２０】本実施形態に係るデータベース管理方法において、選択式のＸＰａｔｈを評価する際の流れを示すフローチャートである。
【符号の説明】
【０１０７】
１ データベース管理装置
５ 情報処理装置
６ ネットワーク
７ データベース管理システム
１０，５０ メインメモリ
２０，５１ ＣＰＵ
３０，５２ 通信部
４０ 補助記憶部
５５ アプリケーション処理部
１００ データベース管理部
１１０ ＳＱＬ解析部
１１１ ＳＱＬ分解部
１１２ ヒント情報解析部
１２０ 定義情報解析部
１２１ ＸＭＬスキーマ解析部
１２２ インデクス構成情報解析部
１３０ ＳＱＬ最適化部
１３１ 共通ＸＰａｔｈ抽出部
１３２ アクセスプラン決定部
１４０ ＳＱＬ実行部
１４１ データベースアクセス部
１４２ 探索条件評価部
１４３ 選択式実行部
２００ ＳＱＬ文
２１０ 選択式から取得した最短経路のＸＰａｔｈ
２２０ 表式から取得した最短経路のＸＰａｔｈ
２３０ 探索条件から取得した最短経路のＸＰａｔｈ
２５０ 共通ＸＰａｔｈ
３００ ＸＭＬスキーマ
４００ インデクス構成情報
５００ アクセスコスト設定情報
６００ データ格納位置情報
７００ ＸＭＬデータ
８００ ヒント情報
【特許請求の範囲】
【請求項１】
構造化データを格納する１つ以上のデータベースが記憶される記憶部と、前記記憶部に記憶されるデータベースの管理を行うデータベース管理部と、を備えたデータベース管理装置が、ＳＱＬ（Structured Query Language）を用いて前記構造化データの処理を行うデータベース管理方法であって、
前記データベース管理部は、
前記構造化データを処理するためのＳＱＬ文を取得し、
前記取得したＳＱＬ文から、前記構造化データのうち処理対象となるデータの格納位置を示すパス全てを抽出し、
前記パスが複数抽出された場合に、
前記抽出されたパスそれぞれと、前記記憶部に記憶された前記構造化データのスキーマとを、ルートノードから前記抽出されたパスそれぞれが示す前記処理対象となるデータの格納位置まで順に比較して、前記抽出されたパスそれぞれにおける前記ルートノードから当該処理対象となるデータの格納位置までの経路のパスを取得し、
前記取得した経路のパスそれぞれを比較して、当該経路のパス同士の共通部分を、共通パスとして抽出し、
前記記憶部に記憶される構造化データにおける前記抽出された共通パスが示す格納位置以降のノードのデータについて、前記ＳＱＬを用いて処理を行うことを特徴とするデータベース管理方法。
【請求項２】
前記データベース管理部は、
前記抽出されたパスそれぞれが、省略記法で指定されている場合には、フルパス記法に変換し、
前記フルパス記法で指定された前記パスそれぞれが、逆文書順の記法で指定されている場合には、文書順の記法に変換すること
を特徴とする請求項１に記載のデータベース管理方法。
【請求項３】
前記ＳＱＬ文は、処理の対象となる前記構造化データを指定する表式と、前記表式で指定された前記構造化データのうち所定の要素が含まれるデータを射影する選択式とを、少なくとも含んでおり、
前記データベース管理部は、
前記ＳＱＬ文を、少なくとも前記表式と、前記選択式とに分解し、
前記分解した表式および前記分解した選択式それぞれから、前記処理対象となるデータの格納位置を示すパスを抽出し、
前記パスが複数抽出された場合に、
前記抽出されたパスそれぞれと、前記記憶部に記憶された前記構造化データのスキーマとを、前記ルートノードから前記抽出されたパスそれぞれが示す前記処理対象となるデータの格納位置まで順に比較して、少なくとも前記表式および前記選択式それぞれにおける前記ルートノードからの経路のパスを取得し、
前記取得した、少なくとも前記表式の前記経路のパスと前記選択式の前記経路のパスとを比較して、当該経路のパスの共通部分を、前記共通パスとして抽出すること
を特徴とする請求項２に記載のデータベース管理方法。
【請求項４】
前記データベース管理部は、
前記抽出された１つ以上の共通パスそれぞれに含まれるノード数をカウントし、少なくとも前記表式および前記選択式それぞれにおいて前記構造化データの処理を行うときに省略できるノード数に応じたアクセスコストを計算し、前記アクセスコストが最小となるようにアクセスプランを決定し、
前記決定したアクセスプランに従い、前記表式で指定される前記構造化データにアクセスし、前記共通パスが示す前記処理対象となる格納位置以降のノードのデータについて、前記選択式に合致する前記データを射影すること
を特徴とする請求項３に記載のデータベース管理方法。
【請求項５】
前記データベース管理部は、
前記共通パスが示す前記処理対象となるデータの格納位置と、前記共通パスで示されるノードの前記構造化データにおける下位のノードである子孫ノードの有無を示す情報とを含むデータ格納位置情報を前記記憶部に記憶し、
前記データ格納位置情報に基づいて前記子孫ノードが存在しないと判断した場合に、
前記共通パスが示す前記処理対象となる格納位置以降のノードのデータについて処理を行わないこと
を特徴とする請求項４に記載のデータベース管理方法。
【請求項６】
前記データ格納位置情報は、少なくとも前記選択式における前記処理対象となるデータの格納位置を示すパスで示されるノードが、所定のノードテストに合致するか否かを示す情報をさらに含み、
前記データベース管理部は、
当該ノードが、前記所定のノードテストに合致しない場合に、当該ノードのデータについて処理を行わないこと
を特徴とする請求項５に記載のデータベース管理方法。
【請求項７】
前記データベース管理部は、
前記ＳＱＬ文に、前記共通パスを用いて処理を行うか否かを指定するヒント情報が含まれているときに、前記ヒント情報に従い、前記共通パスを用いて処理を行うか否かを判断すること
を特徴とする請求項１ないし請求項６のいずれか１項に記載のデータベース管理方法。
【請求項８】
前記データベース管理部は、
アプリケーション単位で共通パスを用いて処理を行うか否かを指定するヒント情報、またはデータベース管理システム単位で共通パスを用いて処理を行うか否かを指定するヒント情報を取得し、前記ヒント情報に従い、前記共通パスを用いて処理を行うか否かを判断すること
を特徴とする請求項１ないし請求項６のいずれか１項に記載のデータベース管理方法。
【請求項９】
前記データベース管理部は、
前記記憶部に、前記構造化データの格納位置を指定するインデクスのインデクス定義情報が記憶されている場合には、
前記処理対象となるデータの格納位置を示すパスそれぞれと、前記記憶部に記憶された前記インデクス定義情報に示されるインデクスキーにより指定される前記構造化データの格納位置を示すパスとを、前記ルートノードから前記インデクスキーにより指定される前記構造化データの格納位置まで順に比較して、前記処理対象となるデータの格納位置を示すパスそれぞれにおける前記ルートノードからの経路の文字列を取得すること
を特徴とする請求項１ないし請求項８のいずれか１項に記載のデータベース管理方法。
【請求項１０】
前記データベース管理部は、
前記記憶部に、前記構造化データのスキーマも、前記構造化データの格納位置を指定するインデクス定義情報も記憶されていない場合に、
前記取得したＳＱＬ文から、前記構造化データのうち処理対象となるデータの格納位置を示すパスの全てを抽出し、前記抽出したパスそれぞれを比較して共通部分を、前記共通パスとして抽出すること
を特徴とする請求項１ないし請求項９のいずれか１項に記載のデータベース管理方法。
【請求項１１】
外部からの処理要求を通信回線を介して受け付ける通信部と、構造化データを格納する１つ以上のデータベースが記憶される記憶部と、前記データベースを管理するデータベース管理部と、を含んで構成されるデータベース管理装置であって、
前記データベース管理部は、
前記通信部を介して、前記記憶部に記憶された前記構造化データを処理するためのＳＱＬ文を取得し、
前記取得したＳＱＬ文から、前記構造化データのうち処理対象となるデータの格納位置を示すパス全てを抽出し、
前記パスが複数抽出された場合に、
前記抽出されたパスそれぞれと、前記記憶部に記憶された前記構造化データのスキーマとを、ルートノードから前記抽出されたパスそれぞれが示す前記処理対象となるデータの格納位置まで順に比較して、前記抽出されたパスそれぞれにおける前記ルートノードから当該処理対象となるデータの格納位置までの経路のパスを取得し、
前記取得した経路のパスそれぞれを比較して、当該経路のパス同士の共通部分を、共通パスとして抽出し、
前記記憶部に記憶される構造化データにおける前記抽出された共通パスが示す格納位置以降のノードのデータについて、前記ＳＱＬを用いて処理を行うこと
を特徴とするデータベース管理装置。
【請求項１２】
請求項１ないし請求項１０のいずれか１項に記載のデータベース管理方法をコンピュータに実行させるためのプログラム。
【請求項１】
構造化データを格納する１つ以上のデータベースが記憶される記憶部と、前記記憶部に記憶されるデータベースの管理を行うデータベース管理部と、を備えたデータベース管理装置が、ＳＱＬ（Structured Query Language）を用いて前記構造化データの処理を行うデータベース管理方法であって、
前記データベース管理部は、
前記構造化データを処理するためのＳＱＬ文を取得し、
前記取得したＳＱＬ文から、前記構造化データのうち処理対象となるデータの格納位置を示すパス全てを抽出し、
前記パスが複数抽出された場合に、
前記抽出されたパスそれぞれと、前記記憶部に記憶された前記構造化データのスキーマとを、ルートノードから前記抽出されたパスそれぞれが示す前記処理対象となるデータの格納位置まで順に比較して、前記抽出されたパスそれぞれにおける前記ルートノードから当該処理対象となるデータの格納位置までの経路のパスを取得し、
前記取得した経路のパスそれぞれを比較して、当該経路のパス同士の共通部分を、共通パスとして抽出し、
前記記憶部に記憶される構造化データにおける前記抽出された共通パスが示す格納位置以降のノードのデータについて、前記ＳＱＬを用いて処理を行うことを特徴とするデータベース管理方法。
【請求項２】
前記データベース管理部は、
前記抽出されたパスそれぞれが、省略記法で指定されている場合には、フルパス記法に変換し、
前記フルパス記法で指定された前記パスそれぞれが、逆文書順の記法で指定されている場合には、文書順の記法に変換すること
を特徴とする請求項１に記載のデータベース管理方法。
【請求項３】
前記ＳＱＬ文は、処理の対象となる前記構造化データを指定する表式と、前記表式で指定された前記構造化データのうち所定の要素が含まれるデータを射影する選択式とを、少なくとも含んでおり、
前記データベース管理部は、
前記ＳＱＬ文を、少なくとも前記表式と、前記選択式とに分解し、
前記分解した表式および前記分解した選択式それぞれから、前記処理対象となるデータの格納位置を示すパスを抽出し、
前記パスが複数抽出された場合に、
前記抽出されたパスそれぞれと、前記記憶部に記憶された前記構造化データのスキーマとを、前記ルートノードから前記抽出されたパスそれぞれが示す前記処理対象となるデータの格納位置まで順に比較して、少なくとも前記表式および前記選択式それぞれにおける前記ルートノードからの経路のパスを取得し、
前記取得した、少なくとも前記表式の前記経路のパスと前記選択式の前記経路のパスとを比較して、当該経路のパスの共通部分を、前記共通パスとして抽出すること
を特徴とする請求項２に記載のデータベース管理方法。
【請求項４】
前記データベース管理部は、
前記抽出された１つ以上の共通パスそれぞれに含まれるノード数をカウントし、少なくとも前記表式および前記選択式それぞれにおいて前記構造化データの処理を行うときに省略できるノード数に応じたアクセスコストを計算し、前記アクセスコストが最小となるようにアクセスプランを決定し、
前記決定したアクセスプランに従い、前記表式で指定される前記構造化データにアクセスし、前記共通パスが示す前記処理対象となる格納位置以降のノードのデータについて、前記選択式に合致する前記データを射影すること
を特徴とする請求項３に記載のデータベース管理方法。
【請求項５】
前記データベース管理部は、
前記共通パスが示す前記処理対象となるデータの格納位置と、前記共通パスで示されるノードの前記構造化データにおける下位のノードである子孫ノードの有無を示す情報とを含むデータ格納位置情報を前記記憶部に記憶し、
前記データ格納位置情報に基づいて前記子孫ノードが存在しないと判断した場合に、
前記共通パスが示す前記処理対象となる格納位置以降のノードのデータについて処理を行わないこと
を特徴とする請求項４に記載のデータベース管理方法。
【請求項６】
前記データ格納位置情報は、少なくとも前記選択式における前記処理対象となるデータの格納位置を示すパスで示されるノードが、所定のノードテストに合致するか否かを示す情報をさらに含み、
前記データベース管理部は、
当該ノードが、前記所定のノードテストに合致しない場合に、当該ノードのデータについて処理を行わないこと
を特徴とする請求項５に記載のデータベース管理方法。
【請求項７】
前記データベース管理部は、
前記ＳＱＬ文に、前記共通パスを用いて処理を行うか否かを指定するヒント情報が含まれているときに、前記ヒント情報に従い、前記共通パスを用いて処理を行うか否かを判断すること
を特徴とする請求項１ないし請求項６のいずれか１項に記載のデータベース管理方法。
【請求項８】
前記データベース管理部は、
アプリケーション単位で共通パスを用いて処理を行うか否かを指定するヒント情報、またはデータベース管理システム単位で共通パスを用いて処理を行うか否かを指定するヒント情報を取得し、前記ヒント情報に従い、前記共通パスを用いて処理を行うか否かを判断すること
を特徴とする請求項１ないし請求項６のいずれか１項に記載のデータベース管理方法。
【請求項９】
前記データベース管理部は、
前記記憶部に、前記構造化データの格納位置を指定するインデクスのインデクス定義情報が記憶されている場合には、
前記処理対象となるデータの格納位置を示すパスそれぞれと、前記記憶部に記憶された前記インデクス定義情報に示されるインデクスキーにより指定される前記構造化データの格納位置を示すパスとを、前記ルートノードから前記インデクスキーにより指定される前記構造化データの格納位置まで順に比較して、前記処理対象となるデータの格納位置を示すパスそれぞれにおける前記ルートノードからの経路の文字列を取得すること
を特徴とする請求項１ないし請求項８のいずれか１項に記載のデータベース管理方法。
【請求項１０】
前記データベース管理部は、
前記記憶部に、前記構造化データのスキーマも、前記構造化データの格納位置を指定するインデクス定義情報も記憶されていない場合に、
前記取得したＳＱＬ文から、前記構造化データのうち処理対象となるデータの格納位置を示すパスの全てを抽出し、前記抽出したパスそれぞれを比較して共通部分を、前記共通パスとして抽出すること
を特徴とする請求項１ないし請求項９のいずれか１項に記載のデータベース管理方法。
【請求項１１】
外部からの処理要求を通信回線を介して受け付ける通信部と、構造化データを格納する１つ以上のデータベースが記憶される記憶部と、前記データベースを管理するデータベース管理部と、を含んで構成されるデータベース管理装置であって、
前記データベース管理部は、
前記通信部を介して、前記記憶部に記憶された前記構造化データを処理するためのＳＱＬ文を取得し、
前記取得したＳＱＬ文から、前記構造化データのうち処理対象となるデータの格納位置を示すパス全てを抽出し、
前記パスが複数抽出された場合に、
前記抽出されたパスそれぞれと、前記記憶部に記憶された前記構造化データのスキーマとを、ルートノードから前記抽出されたパスそれぞれが示す前記処理対象となるデータの格納位置まで順に比較して、前記抽出されたパスそれぞれにおける前記ルートノードから当該処理対象となるデータの格納位置までの経路のパスを取得し、
前記取得した経路のパスそれぞれを比較して、当該経路のパス同士の共通部分を、共通パスとして抽出し、
前記記憶部に記憶される構造化データにおける前記抽出された共通パスが示す格納位置以降のノードのデータについて、前記ＳＱＬを用いて処理を行うこと
を特徴とするデータベース管理装置。
【請求項１２】
請求項１ないし請求項１０のいずれか１項に記載のデータベース管理方法をコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２００９−２９５０１３（Ｐ２００９−２９５０１３Ａ）
【公開日】平成２１年１２月１７日（２００９．１２．１７）
【国際特許分類】
【出願番号】特願２００８−１４９４０５（Ｐ２００８−１４９４０５）
【出願日】平成２０年６月６日（２００８．６．６）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２１年１２月１７日（２００９．１２．１７）
【国際特許分類】
【出願日】平成２０年６月６日（２００８．６．６）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]