JP2008243075A - 構造化文書管理装置及び方法 - Google Patents

Abstract

【課題】より効率的な実行計画を生成することが可能な構造化文書管理装置及び方法を提供する。
【解決手段】予め用意したスキーマ情報を用いて、問合せクエリに応じた最終プラン候補を生成し、この最終プラン候補を、当該最終プラン候補の実行過程で取得した新たなスキーマ情報を用いて変更することで、より効率的な最終プラン候補へと変更する。また、実行処理過程で取得した制約情報を、新たなスキーマ情報として次回以降の問合せクエリのプラン候補生成時に利用する。
【選択図】 図６

Description

本発明は、構造化文書管理装置及び構造化文書管理方法に関する。

従来より、問合せクエリに応じた構造化文書を検索する構造化文書管理装置が用いられている。構造化文書管理装置では、問合せクエリを解析して、効率的な応答性能を実現するための索引作成等の実行計画（検索プラン）を作成し、当該プランに基づいて構造化文書を格納したデータベースに問合せ処理を実施することで、問合せクエリに応じた検索を行うことが可能となっている。

一般に構造化文書管理装置における検索プランの生成では、入力された問合せクエリを解析し、構造化文書管理装置に蓄えられたスキーマ情報等の制約情報や統計情報から得られるオペレータの見積もりコスト等に基づいて、複数の検索プランを検索プラン候補として生成する。そして、生成された検索プラン候補から最も見積もりコストの低いものが最終的に実行される最終プランとして採用されている。ここで生成される検索プランは、与えられたスキーマ情報等の制約情報が多いほど、より効率的な検索プラン候補の生成が可能であり、統計情報の精度が高い程、検索プラン候補の中から最も効率の良い検索プランの選択が可能となる。

また、一般にスキーマ情報は、リレーショナルデータベースに代表されるように、予め構造化文書管理装置内に格納しておく必要がある。これに対し、近年盛んに利用されている構造化文書の１つであるＸＭＬデータを扱うデータベースの分野においては、スキーマ情報の事前準備を必要としないネイティブＸＭＬデータベースと呼ばれる技術が登場している。このネイティブＸＭＬデータベースでは、事前にスキーマ情報の登録を必要としない代わりに、構造化文書の登録時に当該構造化文書の動的に変化する構造上の制約情報を抽出し、これをスキーマ情報として問合せクエリの処理時に利用している（例えば、特許文献１参照）。

一方、ネイティブＸＭＬデータベースを用いた技術では、検索プラン候補を生成する際に、問合せクエリの一部がパラメータ化されている場合や統計情報の精度が低い場合、コストの見積もりの精度が低くなり与えられた検索プラン候補内からの最適な検索プランの選択が困難になるという問題がある。

そのため、上記問題を解決するため種々の技術が提案されており、例えば、特許文献２では、変数パラメータ付の問合せクエリに対して、変数のパラメータの変化により取り得る全パターンの検索プランを保持し、実行時に確定する方法を提案している。また、特許文献３では、コンパイル時にアクセス条件が確定した部分のみをコンパイルし、残りの部分を実行時に決定することで、見積もりが困難な部分の検索プランを実行時に決定する技術が提案されている。

特開２００５−１９０１６３号公報 特許第２７６０７９４号公報 特許第３４３４６４１号公報

ところで、効率の良い検索プランを生成するにはスキーマ情報が多いほどよいが、スキーマ情報を予め用意しておく場合には、スキーマ情報の設計に多くのコストを費やすことや、スキーマ情報に変更があった場合にはスキーマを再設計する必要があるといった問題が生じる。一方、上記従来技術のように、スキーマ情報を予め用意せず登録時に自動抽出を行う場合には、開発者が設計するスキーマ情報と比較して情報量が少なくなり、効率の良い検索プランを生成することが困難となっている。また、スキーマ情報を必要としないことから様々なデータを統合して管理しようとすればするほど共通して得られるスキーマ情報の情報量が低下するという問題がある。

また、従来のプラン生成処理では、検索プランの生成時に用いられるスキーマ等の制約情報は、予め用意されたものが利用されている。そのため、用意された制約情報の情報量が少ない場合、実際には存在する共通の制約や特定の条件下のみ発生する制約、あるいは偶然にある制約となるような特定の特徴を持った場合に、それを利用してクエリ処理を効率化することができなかった。また、従来から存在するパラメータが存在した場合のプラン変更や見積もり誤りの修正によるプラン変更は存在したが、制約情報の変化を考慮するようなものは存在しなかった。そのため、変更する検索プランが既存の検索プラン候補内に限定され、得られた制約情報を他の問合せクエリの検索プラン候補を生成する際に利用することもできなかった。

本発明は上記に鑑みてなされたものであって、より効率的な実行計画を生成することが可能な構造化文書管理装置及び方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、複数の構造化文書を記憶する第１記憶手段と、前記構造化文書の構造を定義したスキーマ情報を記憶する第２記憶手段と、特定の要素を含んだ構造化文書の検索を指示する問合せクエリの入力を受け付ける入力手段と、前記問合せクエリの生成言語に基づいて、当該問合せクエリの構文を解析する解析手段と、前記解析手段により解析された前記問合せクエリの構文及び前記スキーマ情報に基づいて、前記第１記憶手段に対する検索コマンドを指示した複数のオペレータからなる前記構造化文書の検索にかかる実行計画を、検索プラン候補として複数生成するプラン候補生成手段と、所定のルールに基づき、前記複数の検索プラン候補から、一の検索プラン候補を最終プラン候補として選択する選択手段と、前記最終プラン候補に含まれる各オペレータの変数部分の状態遷移を表した状態遷移表を生成する状態遷移表生成手段と、前記最終プラン候補に含まれる各オペレータを順次実行し、当該各オペレータの実行毎に得られる前記変数部分の状態に基づいて、検索対象となった前記構造化文書の構造に関する制約を示した制約情報を取得する実行手段と、前記制約情報を新たなスキーマ情報として、前記スキーマ記憶手段に登録する登録手段と、前記実行手段により得られた前記変数部分の状態と、前記状態遷移表の前記変数部分の状態とを比較し、両状態に差異があるか否かを判定する第１判定手段と、前記第１判定手段による判定の結果、差異があると判定された前記状態遷移表の変数部分を更新する更新手段と、前記更新手段により更新された状態遷移表に基づいて、前記最終プラン候補の内容を変更する変更手段と、を備える。

また、本発明は、特定の要素を含んだ構造化文書の検索を指示する問合せクエリの入力を受け付ける入力工程と、前記問合せクエリの生成言語に基づいて、当該問合せクエリの構文を解析する解析工程と、前記解析工程により解析された前記問合せクエリの構文及び前記構造化文書の構造を定義したスキーマ情報に基づいて、複数の構造化文書が格納された文書記憶手段に対する検索コマンドを指示した複数のオペレータからなる前記構造化文書の検索にかかる実行計画を、検索プラン候補として複数生成するプラン候補生成工程と、所定のルールに基づき、前記複数の検索プラン候補から、一の検索プラン候補を最終プラン候補として選択する選択工程と、前記最終プラン候補に含まれる各オペレータの変数部分の状態遷移を表した状態遷移表を生成する状態遷移表生成工程と、前記最終プラン候補に含まれる各オペレータを順次実行し、当該各オペレータの実行毎に得られる前記変数部分の状態に基づいて、検索対象となった前記構造化文書の構造に関する制約を示した制約情報を新たなスキーマ情報として取得する実行工程と、前記実行工程により得られた前記変数部分の状態と、前記状態遷移表の前記変数部分の状態とを比較し、両状態に差異があるか否かを判定する第１判定工程と、前記第１判定工程による判定の結果、差異があると判定された前記状態遷移表の変数部分を更新する更新工程と、前記更新工程により更新された状態遷移表に基づいて、前記最終プラン候補の内容を変更する変更工程と、を含む。

本発明によれば、予め用意したスキーマ情報を用いて、問合せクエリに応じた最終プラン候補を生成し、この最終プラン候補を当該最終プラン候補の実行過程で取得した新たなスキーマ情報を用いて変更することで、より効率的な実行計画（最終プラン候補）へと変更することができる。また、実行処理過程で取得した制約情報は新たなスキーマ情報として次回以降の問合せクエリのプラン候補生成時に利用できるため、他のクエリ処理に関しても効率化を実現することが可能となる。

以下に添付図面を参照して、構造化文書管理装置及び方法の最良な実施形態を詳細に説明する。図１は、構造化文書管理装置１００のハードウェア構成を示した図である。図１に示すとおり、構造化文書管理装置１００は、ＣＰＵ（Central Processing Unit）
１０１、操作部１０２、表示部１０３、ＲＯＭ（Read Only Memory）１０４、ＲＡＭ（Random Access Memory）１０５、通信部１０６、文書記憶部１０７等を備え、各部はバス１０８により接続されている。

ＣＰＵ１０１は、ＲＡＭ１０５の所定領域を作業領域として、ＲＯＭ１０４に予め記憶された各種制御プログラムとの協働により各種処理を実行し、構造化文書管理装置１００を構成する各部の動作を統括的に制御する。

また、ＣＰＵ１０１は、ＲＯＭ１０４に予め記憶された所定のプログラムとの協働により、後述する問合せ構文解析部１１、プラン候補生成部１２、最終プラン決定部１３、オペレータ実行部１４、制約情報登録部１５、状態遷移表更新部１６、プラン変更部１７及び制約情報管理部１８（図６参照）の各機能部を実現させる。なお、各機能部の動作については後述する。

操作部１０２は、各種入力キー等を備え、ユーザから操作入力された情報を入力信号として受け付け、その入力信号をＣＰＵ１０１に出力する。

表示部１０３は、ＬＣＤ（Liquid Crystal Display）等の表示手段により構成され、ＣＰＵ１０１からの表示信号に基づいて、各種情報を表示する。なお、表示部１０３は、操作部１０２と一体的にタッチパネルを構成する態様としてもよい。

ＲＯＭ１０４は、構造化文書管理装置１００の制御にかかるプログラムや各種設定情報等を書き換え不可能に記憶する。

ＲＡＭ１０５は、ＳＤＲＡＭ等の記憶手段であって、ＣＰＵ１０１の作業エリアとして機能し、バッファ等の役割を果たす。

通信部１０６は、ネットワークを通じ外部の機器との間で通信を行うインターフェースであって、外部機器から送信された各種情報（例えば、後述する問合せクエリやＸＭＬ文書）をＣＰＵ１０１に出力し、また、ＣＰＵ１０１から出力される各種情報（例えば、後述する検索結果）を外部機器へと送信する。

文書記憶部１０７は、磁気的又は光学的に記録可能な記憶媒体を有し、当該記録媒体に構造化文書データベース（ＤＢ）２０及びスキーマデータベース（ＤＢ）２１等データ管理領域が構築されている。

構造化文書ＤＢ２０には、検索対象となるＸＭＬやＳＧＭＬ等で記述された構造化文書が格納されるものとする。ここで、ＳＧＭＬ（Standard Generalized Markup Language）とは、ＩＳＯ（国際標準化機構）で定められた規格であり、マークアップ言語の一つである。また、ＸＭＬ（eXtensible Markup Language）とは、Ｗ３Ｃ（World Wide Web Consortium）にて定められた規格であって、マークアップ言語の一つである。以下、構造化文書としてＸＭＬ形式にて記述された文書（以下、ＸＭＬ文書という）を例に説明をするが、この態様に限らないものとする。

図２は、ＸＭＬ文書の一例を示した図である。ここでは、本の出版年度やタイトル、著者名といった要素を含んだＸＭＬ文書の例を示している。ＸＭＬ文書では、文書の構造の表現にタグが用いられる。タグには、開始タグと終了タグがあり、文書を構成する各要素を開始タグと終了タグで囲むことにより、文書中の文字列（テキスト）区切りと、そのテキストが構造上どの要素を含むのかを明示的に記述することができるようになっている。

ここで、開始タグとは、要素名称を記号「＜」、「＞」で囲んだものであり、終了タグとは開始タグの要素名称と同一の要素名称を記号「＜／」、「＞」で囲んだものである。これら開始タグと終了タグとの組により挟まれた構成要素の内容が、当該開始タグの要素名称に属していることを意味する。また、開始タグと終了タグとの組に挟まれた構成要素に、他の開始タグと終了タグとの組がさらに存在するような場合には、この他の開始タグの要素名称が、当該他の開始タグを挟む開始タグの要素名称に属していることを意味する。

構造化文書ＤＢ２０は、検索対象となる各ＸＭＬ文書を、当該ＸＭＬ文書に含まれる各要素名称をノードとし、構成要素の内容を索引、即ちノードＩＤとする木構造で記憶・管理する。なお、本実施形態では、Ｂ木によるデータ構造により各ＸＭＬ文書を記憶・管理するものとする。

図３及び図４は、図２に示したＸＭＬ文書に関係するスキーマ情報を示している。ここで、図３はＤＴＤ（Document Type Definition）と呼ばれる形式の構造化文書のスキーマ情報であって、スキーマＤＢ２１の文書スキーマ２１１に予め登録されている。ＤＴＤは、要素宣言、属性宣言、実体宣言等の宣言集合から構成される。図３では、「ｂｉｂ」、「ｂｏｏｋ」、「ｔｉｔｌｅ」、「ｅｄｉｔｏｒ」、「ａｕｔｈｏｒ」、「ｆｉｒｓｔ」、「ｌａｓｔ」といった要素宣言を行っている。

ここで、「ｂｉｂ」は、複数の「ｂｏｏｋ」と１つの「ｔｉｔｌｅ」から構成されることを示している。なお要素宣言の末尾に付加されるアスタリスク（＊）は、当該要素宣言の０個以上の繰り返しを許容することを意味している。また、「ａｕｔｈｏｒ」は、「ｆｉｒｓｔ」と「ｌａｓｔ」から構成されていることを示している。

図４は、ＸＭＬ文書の登録時に、後述する制約情報管理部１８により抽出された、構造テンプレートの一例を示した図である。この構造テンプレートは、登録対象となったＸＭＬ文書を構文解析することで得られるＸＭＬ文書の構造上の制約を示しており、抽出された構造テンプレートはスキーマ情報として、スキーマＤＢ２１の文書スキーマ２１１に登録される。図４に示した構造テンプレートでは、ＸＭＬ文書に現れる構造パスに対するその出現数の情報を構造テンプレートとして挙げている。

また、クエリスキーマ２１２には、後述する制約情報登録部１５により取得される、問合せクエリに対応する最終プラン候補の実行時の制約情報が、スキーマ情報として登録される。

本実施形態の構造化文書管理装置１００では、ＤＴＤ形式又は構造テンプレート形式の何れか一方のスキーマ情報のみを文書スキーマ２１１に記憶し、このスキーマ情報を後述するプラン候補の生成時に用いるものとする。なお、この態様に限らず、例えば、ＤＴＤ形式及び構造テンプレート形式のスキーマ情報をともに文書スキーマ２１１に記憶し、問合せクエリの内容に応じ、上述したＤＴＤ形式及び構造テンプレート形式の何れか一方のスキーマ情報を、後述するプラン候補の生成時に用いる態様としてもよい。

図５は、通信部１０６等を介して入力される問合せクエリ３２の例を示した図である。ここでは、ＸＭＬ文書の問合せ言語として、ＸＱｕｅｒｙを用いて記述された三つの問合せクエリ（クエリ１、クエリ２、クエリ３）を示している。

図６は、構造化文書管理装置１００の機能的構成を示したブロック図である。図６に示すように、構造化文書管理装置１００は、問合せ構文解析部１１、プラン候補生成部１２、最終プラン決定部１３、オペレータ実行部１４、制約情報登録部１５、状態遷移表更新部１６、プラン変更部１７及び制約情報管理部１８を有している。

問合せ構文解析部１１は、構文解析手段として機能するものであり、入力された問合せクエリの構文を当該問合せクエリの生成言語に基づいて解析する。

プラン候補生成部１２は、プラン候補生成手段として機能するものであり、問合せ構文解析部１１による構文解析の結果、文書記憶部１０７のスキーマＤＢ２１等に格納された情報に基づいて、実行可能な検索プラン候補を生成する。以下、プラン候補生成部１２による検索プラン候補の生成について説明する。

図７は、上記したスキーマ情報に基づいて生成された、クエリ１〜３に対する検索プラン候補の例を示した図である。図７に示したように、プラン候補生成部１２は、クエリ１〜３の指示内容に基づいて、構造化文書ＤＢ２０に対する検索コマンドを指示した複数のオペレータからなる検索プラン（実行計画）を、検索プラン候補として複数生成する。ここで、図７では、（１）〜（１３）で示したコマンドの夫々がオペレータを意味しており、これらオペレータの組み合わせから、３つの検索プラン候補（検索プラン候補１（１’）、２、３）が生成されたものとする。なお、検索プラン候補１と検索プラン候補１’とは、同一の手順を指示する検索プラン候補であるが、そのオペレータの内容が一部異なるものである。

検索プラン候補１及び１’では、最初にオペレータ（１）において「ｂｉｂ／ｂｏｏｋ／＠ｙｅａｒ」ノードに属する索引を構造化文書ＤＢ２０から取得し、この条件を満たすノードＩＤを「変数＄＿ｔ１」に格納している。次にオペレータ（２）において「変数＄＿ｔ１」に格納されたノードＩＤから親ノードを取得し、そのノードＩＤを「変数＄＿ｔ２」に格納している。

次にオペレータ（３）において「変数＄＿ｔ２」に格納されたノードＩＤから子ノード「ａｕｔｈｏｒ(又はｔｉｔｌｅ)」を取得し、そのノードＩＤを「変数＄＿ｔ３」に格納している。次にオペレータ（４）において「変数＄＿ｔ３」に格納されたノードＩＤから比較条件を満たすもののみを残すよう処理している。以上の処理により全ての条件式を満たすノード「ｂｏｏｋ」が格納された「変数＄＿ｔ２」を検索結果として取得しているが、検索プラン候補１では「変数＄＿ｔ２」内に存在する可能性があるノードＩＤのうち、重複するノードＩＤを削除するため、オペレータ（１２）において「変数＄＿ｔ２」をＩＤ番号に基づいてソートし、最後にオペレータ（１３）によりソートされたノードＩＤを順にチェックして重複したノードＩＤを削除している。なお、検索プラン候補１’ではオペレータ（１２）、（１３）の処理は省略されている。

検索プラン候補２は、オペレータ（１）及び（２）までは検索プラン候補１（１’）と同様であるが、次のオペレータ（５）の処理で「ｂｉｂ／ｂｏｏｋ／ａｕｔｈｏｒ(又はｔｉｔｌｅ)」ノードに対する索引から条件を満たすノード「変数＄＿ｔ３」を取得する。次にオペレータ（１０）で「変数＄＿ｔ３」の親ノードである「変数＄＿ｔ２」を取得する。さらにオペレータ（１１）においてオペレータ（２）及び（１０）で取得した「変数＄＿ｔ２」から共通に存在するノードＩＤのみを残す。残りのオペレータ（１２）、（１３）は検索プラン候補１と同様である。

検索プラン候補３は、索引を使わずにＸＭＬのノードを順に降りていって各条件を満たすノードを取得するようにオペレータ（６）、（７）、（８）、（９）、（３）、（４）を実行し、検索プラン候補１と同様にオペレータ（１２）、（１３）を実行する。

図８は、クエリ１〜３に対する検索プラン候補１と検索プラン候補１’との関係を示した図である。ここで、検索プラン候補１は、スキーマ情報として構造テンプレートを用いた場合での、クエリ１、２、３に対する検索プラン候補であることを示している。また、検索プラン候補１は、スキーマ情報としてＤＴＤを用いた場合での、クエリ２、３に対する検索プラン候補であることを示している。検索プラン候補１’は、スキーマ情報としてＤＴＤを用いた場合での、クエリ１に対する検索プラン候補であることを示している。

図６に戻り、最終プラン決定部１３は、選択手段及び状態遷移表生成手段として機能するものであり、所定のルールに基づいて、プラン候補生成部１２で生成された複数の検索プラン候補から、一の検索プラン候補を最終プラン候補として選択し、当該最終プラン候補に含まれる各オペレータの変数部分の状態遷移を表した状態遷移表を生成する。

具体的に、最終プラン決定部１３は、プラン候補生成部１２により生成された上記３つの検索プラン候補の夫々について、各検索プラン候補で指示されたオペレータの組み合わせを順次実行した際の所要時間を見積もり、この所用時間を見積もりコストとして導出する。そして、プラン候補生成部１２は、見積もりコストが最も低い検索プラン候補、即ち、実行した際の所用時間が最も短くなる検索プラン候補を最終プラン候補として決定する。なお、本実施形態では、図７中の検索プラン候補１（１’）が最終プラン候補として決定されたものとする。

図９−1は、検索プラン候補１に含まれる各オペレータの内容を示した図であり、図９−２は、検索プラン候補１の状態遷移表を示した図である。また、図１０−１は、検索プラン候補１’に含まれる各オペレータの内容を示した図であり、図１０−２は、検索プラン候補１’の状態遷移表を示した図である。ここで、状態遷移表は、各オペレータの実行後における変数部分の状態を、各オペレータに実行順序に沿って示したものである。変数部分の状態の一例としては、ＩＤに関するソート状態や重複状態、値に関するソート状態や重複状態、型情報等が挙げられる。以下、図９−２及び図１０−２を参照して、状態遷移表に含まれた各変数部分の状態について説明する。

図９−２、１０−２に示したように、オペレータ（１）の実行後では、検索プラン候補１及び検索プラン候補１’では「変数＄＿ｔ１」に格納されるノードＩＤはともにユニークとなり、その値の大きさ順にソートした状態で取得される。これは、索引がＢ木で構築されているためであり、索引が返す変数部分の状態の特性に起因するものである。また、オペレータ（２）の実行後においても「変数＄＿ｔ１」の状態は変化せず、「変数＄＿ｔ２」では格納されるノードＩＤがユニークとなる。これは「変数＄＿ｔ２」に格納されるノードＩＤに対して親ノードは１つしか存在しないため、「変数＄＿ｔ１」がユニークであれば「変数＄＿ｔ２」もユニークとなるためである。

次に、検索プラン候補１では、図９−２に示したように、オペレータ（３）において「変数＄＿ｔ１」及び「変数＄＿ｔ２」でのノードＩＤのユニーク性は消失する。これは図３及び図４におけるＤＴＤ及び構造テンプレートのいずれにおいても「変数＄＿ｔ２」の「ｂｏｏｋ」ノードに対して子ノード「ａｕｔｈｏｒ」が１つであることが保証されていないためである。そのため「ａｕｔｈｏｒ」が複数になった場合、各「ａｕｔｈｏｒ」に対して同じｂｏｏｋノードが対応付けられるため、ＩＤのユニーク性は失われる。

子ノード「ｔｉｔｌｅ」に関しては、図３のＤＴＤでは必ず１つ持つことがスキーマ情報から判明するため、図１０−２に示した検索プラン候補１’の状態遷移表のように、「変数＄＿ｔ１」及び「変数＄＿ｔ２」でのノードＩＤはユニーク性を維持する。しかしながら、図４に示した構造テンプレートのスキーマ情報では、「ｔｉｔｌｅ」ノードが１つであることを保証できないため検索プラン候補１のようにユニーク性の保証が失われた状態となる。

続くオペレータ（４）では、条件を満たさないノードを削除するだけなので、検索プラン候補１及び検索プラン候補１’ともに、オペレータ（３）の状態から変化しない。ここで、検索プラン候補１’の状態遷移表では、図１０−２に示したように、オペレータ（４）の後でも「変数＄＿ｔ２」のＩＤはユニークである。そのため、ノードＩＤをユニークにするための処理であるオペレータ（１２）、（１３）が不要となる。このように、図３に示したＤＴＤが文書スキーマ２１１に予め記憶されており、且つ、図２に示したクエリ１が入力された場合では、検索プラン候補１‘を生成することが可能となり、他の場合と比較して無駄な処理を回避することが可能となる。

図６に戻り、オペレータ実行部１４は、実行手段として機能するものであり、生成された検索プラン候補内において処理されていないオペレータが存在する場合はそのオペレータを実行し、存在しない場合は得られた検索結果を、通信部１０６等を介してクライアント端末に提供する。

オペレータ実行部１４は、オペレータを処理する際に入力された変数に対して演算処理を実施していく過程で、保持している変数や新たに作成する変数や変数間が持つ制約情報を検出する。ここで得られる制約情報とは、ノード間の関係や、ノードのＩＤや値の順序性、型情報等が例として挙げられる。特にノード間の関係は、構造化文書特有の重要な情報であり、このような情報を検出することはクエリの最適化において重要な役割を果たす。

また、ここで得られる制約情報は、文書スキーマ２１１に記憶した汎用的に用いるスキーマ情報では定義するこが不可能な特定の条件下における制約情報（制約条件）であって、例えば、現在登録されたＸＭＬ文書においてのみ成立するような制約情報となっている。このような制約情報は、最終プラン候補の実行時以外で取得することが困難なものであるため、本実施形態では、最終プラン候補に含まれた各オペレータの実行時に、制約情報の取得を行い、この制約情報を新たなスキーマ情報とする。

以下、図１１及び図１２を参照して、制約情報の取得について説明する。図１１−１は、図７の検索プラン候補１を最終プラン候補として採用し、クエリ１についてオペレータ（３）を実行した場合での制約情報の取得過程を説明するための図である。オペレータ実行部１４は、クエリ１において、オペレータ（１）及び（２）を実行した結果、全ての「ｂｏｏｋ」ノードが「変数＄＿ｔ２」に格納されたことを検出する。

この状態において、オペレータ実行部１４は、オペレータ（３）の実行により、「ｂｏｏｋ」ノードから「ｔｉｔｌｅ」ノードを取得していく際に、１つの「ｂｏｏｋ」ノードから取得される「ｔｉｔｌｅ」ノードの個数を記憶することで、「ｂｏｏｋ」と「ｔｉｔｌｅ」ノードが１対１の関係、即ちユニークに存在していることを検出する。そして、オペレータ実行部１４は、図２で示した構造化文書に基づき、全ての索引に「ｂｏｏｋ」の要素が格納されていることを確認すると、制約情報として図１１−２に示した＜！ＥＬＥＭＥＮＴ ｂｏｏｋ （ｔｉｔｌｅ）＞を取得する。これは図３のＤＴＤにおいては既に定義されているが、図４の構造テンプレートの場合には定義されていないため、新たな制約情報（スキーマ情報）として取得を行う。

また図１２−１は、図７の検索プラン候補１を最終プラン候補として採用し、クエリ３についてオペレータ（３）を実行した場合での制約情報の取得過程を説明するための図である。オペレータ実行部１４は、クエリ３について、オペレータ（１）及び（２）を実行した結果、４件中２件の「ｂｏｏｋ」ノードが「変数＄＿ｔ２」に格納されたことを検出する。

この状態において、オペレータ実行部１４は、オペレータ（３）により「ｂｏｏｋ」ノードから「ａｕｔｈｏｒ」ノードを取得していく際に、１つの「ｂｏｏｋ」ノードから取得される「ａｕｔｈｏｒ」ノードの個数を記憶することで「ｂｏｏｋ」と「ａｕｔｈｏｒ」ノードとが１対１の関係、即ちユニークに存在していることを検出する。この場合、オペレータ実行部１４は、図３で示した構造化文書に基づき、属性「ｙｅａｒ」が１９９９以上の値を満たす「ｂｏｏｋ」ノードにのみ「ａｕｔｈｏｒ」ノードが格納されていると判断するため、オペレータ実行部１４は、条件付の制約情報として、図１２−２で示した＜！ＥＬＥＭＥＮＴ ｂｏｏｋ （ａｕｔｈｏｒ）＞ 条件 ＠ｙｅａｒ＞＝１９９９を取得する。これは図３のＤＴＤにも定義されておらず、何れのスキーマにおいても新たな制約情報として取得される。これらの情報はオペレータ実行中の処理を利用して取得されるため少ないコストで処理することが可能である。

図６に戻り、制約情報登録部１５では、登録手段として機能するものであり、オペレータ実行部１４において検出した制約情報を、スキーマＤＢ２１のクエリスキーマ２１２に登録する。ここで、制約情報を登録する際には、登録の妥当性を検証した後、所定の基準を満たしたもののみを登録するものとする。なお、妥当性の判断基準は無条件でも良いし、一定の汎用性があると判断した場合のみでも良い。また、クエリスキーマ２１２で既に登録されたクエリスキーマの制約情報を包含するものであればその制約情報を上書きしても良い。また、クエリスキーマ２１２で既に登録されたクエリスキーマの制約情報に包含されるような場合には、妥当性がないと判断し登録しないよう制御してもよい。また、クエリスキーマ２１２の登録数が多くなったと判断した場合には、予め定められた閾値に基づいてクエリスキーマ２１２内の制約情報を削除し、登録数が増えすぎないよう制御する態様としてもよい。

図１３は、クエリスキーマ２１２に格納（追加）された制約情報（ＤＴＤ）の一例を示した図である。ここでは、クエリ１〜３を、図４に示した構造テンプレートを用いて実行した際に取得された制約情報を示している。このように、取得した制約情報をクエリスキーマ２１２に格納することで、次回以降のクエリに関しては、プラン候補を生成する際にこの制約情報を参照することが可能となる。

状態遷移表更新部１６は、第１判定手段及び更新手段として機能するものであり、オペレータ実行部１４で検出した制約情報から得られる変数部分の状態が、最終プラン決定部１３で取得された状態遷移表と異なるか否かを判定し、異なる場合は状態遷移表の変数部分の状態を順次更新する。

図１４は、状態遷移表更新部１６により更新された状態遷移表の一例を示した図である。ここで、図１４は、図９−２で示した状態遷移表が更新されたものであって、クエリ１に対し検索プラン候補１を最終プラン候補として採用した場合での、オペレータ（３）実行後における各変数部分の状態に基づいて変更された状態を示している。

具体的に、状態遷移表更新部１６は、オペレータ実行部１４での実行時における各オペレータの変数部分の状態と、図９−２で示した状態遷移表での各オペレータ実行時における変数部分の状態とを比較し、両状態に差異があるか否かを判定する。そして、状態遷移表更新部１６は、両状態に差異があると判定すると、差異を確認した状態遷移表の変数部分の状態を順次更新して行く。

図１４の状態遷移表では、更新された変数部分の状態を破線で示しており、オペレータ（３）、（４）において、「変数＄＿ｔ１」及び「変数＄＿ｔ２」のノードＩＤがユニークとなるよう状態が更新されており、また、オペレータ（１２）において、「変数＄＿ｔ２」のノードＩＤがユニークとなるよう状態が更新されている。

プラン変更部１７は、変更手段として機能するものであり、状態遷移表更新部１６において状態遷移表が更新された場合、更新された情報により最終プラン候補を変更するべきか否かを判定し、変更する場合は最終プラン候補を更新する。なお、最終プラン候補の変更は、全てのオペレータを実行した後に行う態様としてもよいし、各オペレータの実行途中において、処理済みのオペレータから得られた結果に基づき、未処理のオペレータ部分に関してのみ変更する態様としてもよい。また、各オペレータの実行途中で処理を中段し、処理済みのオペレータから得られた結果に基づいて、新たな最終プラン候補を生成し直す態様としてもよい。

図１５は、図１４の状態遷移表に基づいて、検索プラン候補１を変更する際の過程を説明するための図である。プラン変更部１７は、更新後の状態遷移表に基づいて、上述した検索プラン候補１に含まれる各変数の値をオペレータの実行順序に応じて順次検証する。

具体的に、プラン変更部１７は、まずオペレータ（１）において「ｂｉｂ／ｂｏｏｋ／＠ｙｅａｒ」属性ノードに対する索引から、条件「１９９０（１９９９）以上」を満たすノードＩＤを「変数＄＿ｔ１」に格納する。次にプラン変更部１７は、オペレータ（２）において「変数＄＿ｔ１」に格納されたノードＩＤから親ノードを取得し、そのノードＩＤを「変数＄＿ｔ２」に格納する。

次にプラン変更部１７は、オペレータ（３）において「変数＄＿ｔ２」に格納されたノードから子ノード「ａｕｔｈｏｒ(又はｔｉｔｌｅ)」を取得して「変数＄＿ｔ３」に格納する。ここで、オペレータ（３）に終了後における「変数＄＿ｔ１」及び「変数＄＿ｔ２」のノードＩＤの状態は、図１４からも明らかなようにユニークとなる。

続いてプラン変更部１７は、オペレータ（４）において「変数＄＿ｔ３」に格納されたノードＩＤから比較条件を満たすもののみを残すように処理する。なお、このオペレータ（４）実行後においても、「変数＄＿ｔ２」に格納されたノードＩＤの状態は、ユニークのまま維持される。

次いでプラン変更部１７は、「変数＄＿ｔ２」のノードＩＤをユニークにするために実施する上述したオペレータ（１２）及び（１３）の処理において、両処理の実施に伴う追加条件「変数＄＿ｔ２＝ｎｏｔ（ＩＤユニーク）＆＆ｎｏｔ（ＩＤソート）」及び「変数＄＿ｔ２＝ｎｏｔ（ＩＤユニーク）」、即ち、「変数＄＿ｔ２」のノードＩＤがユニークでないことを前提とする条件から、両処理を不要と判断し、当該オペレータ（１２）及び（１３）を削除することで、最終プラン候補である検索プラン候補１の内容を変更する。

図１６は、変更後の検索プラン候補１の内容を示した図である。図１６に示したように、変更後の検索プラン候補１は、従前の検索プラン候補１よりも見積もりコストの低い検索プラン候補１’と同様の内容となっている。このように、プラン変更部１７では、実行中に検出された制約情報及び更新後の状態遷移表を利用して、最終プラン決定部１３で決定された最終プラン候補を、より効率的な最終プラン候補へと変更する。

図１７は、プラン変更後における、各クエリに対する検索プラン候補１と検索プラン候補１’との関係を示した図である。ここでは、図１６で示したように変更後の検索プラン候補１が検索プラン候補１’と同様であることから、変更後の検索プラン候補１を検索プラン候補１’として示している。なお、検索プラン候補１については、図９−１で示した変更前の状態にあるものとする。

図１７において、「プラン更新後」にかかるカラムは、プラン変更後における各クエリに対する検索プラン候補１と、検索プラン候補１’との関係を示している。ここで、クエリ２に対しては変更後の検索プラン候補１が用いられるようになっており、クエリ１、３に対しては検索プラン候補１’が用いられるようになっている。即ち、プラン更新後は、スキーマ情報として構造化テンプレート又はＤＴＤを用いた場合よりも、見積もりコストの低くなる検索プラン候補１’を多く用いて問合せクエリを処理することができるため、より効率的な処理を実現することが可能となる。

また、次回以降入力される問合せクエリについての検索プラン候補の生成に際し、プラン候補生成部１２は、文書スキーマ２１１に格納されたスキーマ情報とともに、クエリスキーマ２１２に格納されたスキーマ情報（制約情報）を用いることで、クエリ内容に応じて最適化された検索プラン候補を生成することが可能となる。例えば、次にクエリ１又３が入力された場合には、最適化された図１６と同様の検索プラン候補を生成することができる。

制約情報管理部１８は、制約情報管理手段として機能するものであり、入力されたＸＭＬ文書を文書記憶部１０７の構造化文書ＤＢ２０に登録するとともに、当該ＸＭＬ文書を生成言語に基づいて構文解析することで、この構文解析結果から構造テンプレートを抽出し、文書スキーマ２１１に登録する。なお、構造テンプレートによるスキーマ情報を用いない態様とする場合には、文書スキーマ２１１への登録は行わないものとする。

また、制約情報管理部１８は、ＸＭＬ文書から抽出した構造テンプレートが、クエリスキーマ２１２に格納されたスキーマ情報による条件を満たすか否かを判定し、満たさないと判定した場合には、この制約情報をクエリスキーマ２１２から削除する。このように、実行中に取得した制約情報の妥当性を検査することで、有用な制約情報のみをスキーマ情報として保持することができる。なお、ＸＭＬ文書登録時における制約情報の検査にかかるコストを省くために、新たなＸＭＬ文書が登録された時点でクエリスキーマ２１２に格納された制約情報を削除する態様としてもよい。この場合、問合せクエリの実行中に得られた制約情報は、新たなＸＭＬ文書が登録される毎にクリアされることになる。

以上のように、本実施形態の構造化文書管理装置１００によれば、予め用意したスキーマ情報を用いて、問合せクエリに応じた最終プランを生成し、この最終プランを当該最終プランの実行過程で取得した新たなスキーマ情報を用いて変更することで、より効率的な実行計画（最終プラン候補）へと変更することができる。また、実行処理過程で取得した制約情報は新たなスキーマ情報として次回以降の問合せクエリのプラン候補生成時に利用できるため、他のクエリ処理に関しても効率化を実現することが可能となる。

以上、発明の実施の形態について説明したが、本発明はこれに限定されるものではなく、本発明の主旨を逸脱しない範囲での種々の変更、置換、追加等が可能である。

構造化文書管理装置の物理的構成を示した図である。 構造化文書の例を示した図である。 スキーマ情報の例を示した図である。 スキーマ情報の例を示した図である。 問合せクエリの例を示した図である。 構造化文書管理装置の機能的構成を示した図である。 検索プラン候補の例を示した図である。 検索プラン候補１と検索プラン候補１’との関係を示した図である。 検索プラン候補１の内容を示した図である。 検索プラン候補１の状態遷移表を示した図である。 検索プラン候補１’の内容を示した図である。 検索プラン候補１’の状態遷移表を示した図である。 制約情報の取得過程を説明するための図である。 制約情報の例を示した図である。 制約情報の取得過程を説明するための図である。 制約情報の例を示した図である。 制約情報の例を示した図である。 検索プラン候補１の状態遷移表の例を示した図である。 プラン変更部１７の動作を説明するための図である。 検索プラン候補１の内容を示した図である。 検索プラン候補１と検索プラン候補１’との関係を示した図である。

符号の説明

１００ 構造化文書管理装置
１０１ ＣＰＵ
１０２ 操作部
１０３ 表示部
１０４ ＲＯＭ
１０５ ＲＡＭ
１０６ 通信部
１０７ 文書記憶部
１０８ バス
１１ 問合せ構文解析部
１２ プラン候補生成部
１３ 最終プラン決定部
１４ オペレータ実行部
１５ 制約情報登録部
１６ 状態遷移表更新部
１７ プラン変更部
１８ 制約情報管理部
２０ 構造化文書データベース（ＤＢ）
２１ スキーマデータベース（ＤＢ）
２１１ 文書スキーマ
２１２ クエリスキーマ

Claims (5)

1. 複数の構造化文書を記憶する第１記憶手段と、
   前記構造化文書の構造を定義したスキーマ情報を記憶する第２記憶手段と、
   特定の要素を含んだ構造化文書の検索を指示する問合せクエリの入力を受け付ける入力手段と、
   前記問合せクエリの生成言語に基づいて、当該問合せクエリの構文を解析する解析手段と、
   前記解析手段により解析された前記問合せクエリの構文及び前記スキーマ情報に基づいて、前記第１記憶手段に対する検索コマンドを指示した複数のオペレータからなる前記構造化文書の検索にかかる実行計画を、検索プラン候補として複数生成するプラン候補生成手段と、
   所定のルールに基づき、前記複数の検索プラン候補から、一の検索プラン候補を最終プラン候補として選択する選択手段と、
   前記最終プラン候補に含まれる各オペレータの変数部分の状態遷移を表した状態遷移表を生成する状態遷移表生成手段と、
   前記最終プラン候補に含まれる各オペレータを順次実行し、当該各オペレータの実行毎に得られる前記変数部分の状態に基づいて、検索対象となった前記構造化文書の構造に関する制約を示した制約情報を取得する実行手段と、
   前記制約情報を新たなスキーマ情報として、前記スキーマ記憶手段に登録する登録手段と、
   前記実行手段により得られた前記変数部分の状態と、前記状態遷移表の前記変数部分の状態とを比較し、両状態に差異があるか否かを判定する第１判定手段と、
   前記第１判定手段による判定の結果、差異があると判定された前記状態遷移表の変数部分を更新する更新手段と、
   前記更新手段により更新された状態遷移表に基づいて、前記最終プラン候補の内容を変更する変更手段と、
   を備えたことを特徴とする構造化文書管理装置。
2. 前記選択手段は、前記複数の検索プラン候補の実行時間を見積もり、当該実行時間が最も短い検索プラン候補を、前記最終プラン候補として選択することを特徴とする請求項１に記載の構造化文書管理装置。
3. 前記文書記憶手段に新たな構造化文書を登録する際に、当該構造化文書の構造が前記スキーマ情報として登録された制約情報を満たすか否かを判定する第２判定手段と、
   前記第２判定手段による判定の結果、満たさないと判定された制約情報を削除する削除手段と、
   を更に備えたことを特徴とする請求項１に記載の構造化文書管理装置。
4. 前記実行手段は、前記検索対象となった構造化文書に含まれる各要素間の関係に基づいて、前記制約情報を取得することを特徴とする請求項１に記載の構造化文書管理装置。
5. 特定の要素を含んだ構造化文書の検索を指示する問合せクエリの入力を受け付ける入力工程と、
   前記問合せクエリの生成言語に基づいて、当該問合せクエリの構文を解析する解析工程と、
   前記解析工程により解析された前記問合せクエリの構文及び前記構造化文書の構造を定義したスキーマ情報に基づいて、複数の構造化文書が格納された文書記憶手段に対する検索コマンドを指示した複数のオペレータからなる前記構造化文書の検索にかかる実行計画を、検索プラン候補として複数生成するプラン候補生成工程と、
   所定のルールに基づき、前記複数の検索プラン候補から、一の検索プラン候補を最終プラン候補として選択する選択工程と、
   前記最終プラン候補に含まれる各オペレータの変数部分の状態遷移を表した状態遷移表を生成する状態遷移表生成工程と、
   前記最終プラン候補に含まれる各オペレータを順次実行し、当該各オペレータの実行毎に得られる前記変数部分の状態に基づいて、検索対象となった前記構造化文書の構造に関する制約を示した制約情報を新たなスキーマ情報として取得する実行工程と、
   前記実行工程により得られた前記変数部分の状態と、前記状態遷移表の前記変数部分の状態とを比較し、両状態に差異があるか否かを判定する第１判定工程と、
   前記第１判定工程による判定の結果、差異があると判定された前記状態遷移表の変数部分を更新する更新工程と、
   前記更新工程により更新された状態遷移表に基づいて、前記最終プラン候補の内容を変更する変更工程と、
   を含むことを特徴とする構造化文書管理方法。

Images