JP3492247B2 - Ｘｍｌデータ検索システム - Google Patents
Ｘｍｌデータ検索システムInfo
- Publication number
- JP3492247B2 JP3492247B2 JP20390899A JP20390899A JP3492247B2 JP 3492247 B2 JP3492247 B2 JP 3492247B2 JP 20390899 A JP20390899 A JP 20390899A JP 20390899 A JP20390899 A JP 20390899A JP 3492247 B2 JP3492247 B2 JP 3492247B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- search
- index
- xml
- xml data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】本発明は、ＸＭＬで記述され
た大量のデータを関係データベースに格納し、検索する
ＸＭＬデータの検索システムに関し、特に、ＸＭＬ文書
の構造に依存せずにあらゆるＸＭＬデータを格納できる
ようにし、また格納されたＸＭＬデータに対するＸＭＬ
の木構造を辿る問い合わせを高速に実行できるようにし
たＸＭＬデータの検索システムに関するものである。
た大量のデータを関係データベースに格納し、検索する
ＸＭＬデータの検索システムに関し、特に、ＸＭＬ文書
の構造に依存せずにあらゆるＸＭＬデータを格納できる
ようにし、また格納されたＸＭＬデータに対するＸＭＬ
の木構造を辿る問い合わせを高速に実行できるようにし
たＸＭＬデータの検索システムに関するものである。
【０００２】
【従来の技術】現在、ＸＭＬデータを格納するのに用い
られている手法は、大まかに次の２つのタイプに分類す
ることができる。 ファイル格納：ＸＭＬ文書をファイル形式のまま格納
する手法。この手法は、オリジナルのＸＭＬファイルの
全体あるいは一部をそのまま利用することを目的として
おり、そのため、ＸＭＬ文書をファイル形式のまま格納
する。しかし、それだけでは、ファイルの数が増えたと
きに目的とするファイルを見つけ出すことが困難になる
ので、目的とするファイルを検索する為のインデックス
も用意しておく必要がある。
られている手法は、大まかに次の２つのタイプに分類す
ることができる。 ファイル格納：ＸＭＬ文書をファイル形式のまま格納
する手法。この手法は、オリジナルのＸＭＬファイルの
全体あるいは一部をそのまま利用することを目的として
おり、そのため、ＸＭＬ文書をファイル形式のまま格納
する。しかし、それだけでは、ファイルの数が増えたと
きに目的とするファイルを見つけ出すことが困難になる
ので、目的とするファイルを検索する為のインデックス
も用意しておく必要がある。
【０００３】テーブル格納：ＸＭＬを関係データベー
スのテーブルにマッピングして格納する手法。この手法
ではＸＭＬ文書を構造化データと見なし、データベース
に格納することによって高速な検索を行なうことを目的
としている。そのため、この手法では、各エレメントを
関係データベースのテーブルの各カラムにマツピングし
て格納する。ＸＭＬデータをテーブルにマツピングする
為には、ＸＭＬの各エレメントをテーブルの各カラムに
どのようにマツピングするかというマツピング規則が必
要である。このマツピング規則はユーザが事前に指定す
る必要がある。
スのテーブルにマッピングして格納する手法。この手法
ではＸＭＬ文書を構造化データと見なし、データベース
に格納することによって高速な検索を行なうことを目的
としている。そのため、この手法では、各エレメントを
関係データベースのテーブルの各カラムにマツピングし
て格納する。ＸＭＬデータをテーブルにマツピングする
為には、ＸＭＬの各エレメントをテーブルの各カラムに
どのようにマツピングするかというマツピング規則が必
要である。このマツピング規則はユーザが事前に指定す
る必要がある。
【０００４】
【発明が解決しようとする課題】ＸＭＬデータを格納す
る際に一番問題となるのは、そのデータ構造が一意に定
まっていないという事である。特に、ＤＴＤ（文書型宣
言) のないＸＭＬデータでは、どこにどのようなタグが
出現するか分からず、データ構造は全く分からない。Ｄ
ＴＤのあるＸＭＬデータでさえも、ＤＴＤの中でタグの
繰り返しやタグの選択、タグの再帰的な宣言が許されて
いるので、データ構造が一意に定まらない。なお、この
ようなデータを半構造データと呼ぶ。このようなデータ
構造の定まっていないＸＭＬデータを格納しようとする
と、格納スキーマの設計が問題となる。例えば、図８に
示される〔ＤＴＤ〕を持つ、サンプルＸＭＬデータ〔Ｘ
ＭＬデータ〕をテーブル格納でデータベースに格納した
場合を考える。なお、このサンプルＸＭＬデータは、２
冊の本の情報を含む書籍目録のデータである。
る際に一番問題となるのは、そのデータ構造が一意に定
まっていないという事である。特に、ＤＴＤ（文書型宣
言) のないＸＭＬデータでは、どこにどのようなタグが
出現するか分からず、データ構造は全く分からない。Ｄ
ＴＤのあるＸＭＬデータでさえも、ＤＴＤの中でタグの
繰り返しやタグの選択、タグの再帰的な宣言が許されて
いるので、データ構造が一意に定まらない。なお、この
ようなデータを半構造データと呼ぶ。このようなデータ
構造の定まっていないＸＭＬデータを格納しようとする
と、格納スキーマの設計が問題となる。例えば、図８に
示される〔ＤＴＤ〕を持つ、サンプルＸＭＬデータ〔Ｘ
ＭＬデータ〕をテーブル格納でデータベースに格納した
場合を考える。なお、このサンプルＸＭＬデータは、２
冊の本の情報を含む書籍目録のデータである。
【０００５】図９は上記ＸＭＬデータをテーブルに格納
した様子を示す図である。図９のテーブルでは、１タプ
ルが本１冊分の情報に相当していて、列にはＸＭＬデー
タ中で出現する可能性のある全てのタグがとられてい
る。これを見ると、一見サンプルデータが問題なく格納
されているかのように見える。しかし、サンプルデータ
のＤＴＤに書かれた定義には著者数の制限が無いのに、
図９のテーブルでは著者を格納するスペースは最大２人
分しか用意されていない。もしＸＭＬデータの中に著者
がそれ以上存在したら、そのデータは格納できないか、
格納しても情報が一部欠損することになる。このよう
に、テーブル格納では、ＸＭＬのＤＴＤで記述される繰
り返しタグを格納することができない。これは、テーブ
ル格納ではあらかじめ格納する要素を列として指定して
おく必要があるので、最大数が未定の繰り返し要素を表
現できないからである。また、同じ理由で再帰的に定義
されているタグも格納できない。さらに、そもそもＸＭ
ＬデータにＤＴＤが存在しなくて、どのようなタグが出
現するか分かっていないときには、テーブルの構造を決
められず、全く対応できない。
した様子を示す図である。図９のテーブルでは、１タプ
ルが本１冊分の情報に相当していて、列にはＸＭＬデー
タ中で出現する可能性のある全てのタグがとられてい
る。これを見ると、一見サンプルデータが問題なく格納
されているかのように見える。しかし、サンプルデータ
のＤＴＤに書かれた定義には著者数の制限が無いのに、
図９のテーブルでは著者を格納するスペースは最大２人
分しか用意されていない。もしＸＭＬデータの中に著者
がそれ以上存在したら、そのデータは格納できないか、
格納しても情報が一部欠損することになる。このよう
に、テーブル格納では、ＸＭＬのＤＴＤで記述される繰
り返しタグを格納することができない。これは、テーブ
ル格納ではあらかじめ格納する要素を列として指定して
おく必要があるので、最大数が未定の繰り返し要素を表
現できないからである。また、同じ理由で再帰的に定義
されているタグも格納できない。さらに、そもそもＸＭ
ＬデータにＤＴＤが存在しなくて、どのようなタグが出
現するか分かっていないときには、テーブルの構造を決
められず、全く対応できない。
【０００６】一方、ファイル格納は、ＸＭＬデータをフ
ァイル形式のまま格納するので、ＤＴＤの無いＸＭＬデ
ータであろうと半構造のＸＭＬデータであろうと、格納
できないＸＭＬデータは存在しない。しかし、それだけ
では大量に格納されたデータの中から自分の求める情報
だけを検索することができないので、検索用のインデッ
クスが必要となる。インデックスの構成は目的に応じて
色々と考えられ、簡単なものではタグ名と文字列の組を
キーにして、そのタグに囲まれてその文字列が出現して
いるようなＸＭＬ文書を検索してくるというものがあ
る。しかし、そのような簡単なインデックスでは、タグ
の階層構造を考慮した検索は行なえない。タグの階層構
造の情報を持つようにインデックスを工夫することも考
えられるが、それでもなお次のことが問題として残る。
ァイル形式のまま格納するので、ＤＴＤの無いＸＭＬデ
ータであろうと半構造のＸＭＬデータであろうと、格納
できないＸＭＬデータは存在しない。しかし、それだけ
では大量に格納されたデータの中から自分の求める情報
だけを検索することができないので、検索用のインデッ
クスが必要となる。インデックスの構成は目的に応じて
色々と考えられ、簡単なものではタグ名と文字列の組を
キーにして、そのタグに囲まれてその文字列が出現して
いるようなＸＭＬ文書を検索してくるというものがあ
る。しかし、そのような簡単なインデックスでは、タグ
の階層構造を考慮した検索は行なえない。タグの階層構
造の情報を持つようにインデックスを工夫することも考
えられるが、それでもなお次のことが問題として残る。
【０００７】（１）インデックスがＸＭＬの木構造の全
ての情報を持っていないので、ＸＭＬデータの全情報を
使った検索ができない。 （２）インデックスが木構造を辿ることに最適化されて
いないので、そのような検索を行った場合は検索速度が
遅い。以上のように、データ構造が一意に定まっていな
いＸＭＬデータにおいては、いかにしてＤＴＤ無しのＸ
ＭＬデータや半構造のＸＭＬデータを格納するか、ま
た、格納されたＸＭＬデータに対していかにして木構造
を辿るような複雑な問い合わせを高速に実行できるよう
にするかといった問題がある。本発明は上記した事情に
鑑みなされたものであって、本発明の目的は、データ構
造が一意に定まっていないＸＭＬデータをデータベース
に格納し、複雑な間合わせを高速に実行することができ
るＸＭＬデータの検索システムを提供することである。
ての情報を持っていないので、ＸＭＬデータの全情報を
使った検索ができない。 （２）インデックスが木構造を辿ることに最適化されて
いないので、そのような検索を行った場合は検索速度が
遅い。以上のように、データ構造が一意に定まっていな
いＸＭＬデータにおいては、いかにしてＤＴＤ無しのＸ
ＭＬデータや半構造のＸＭＬデータを格納するか、ま
た、格納されたＸＭＬデータに対していかにして木構造
を辿るような複雑な問い合わせを高速に実行できるよう
にするかといった問題がある。本発明は上記した事情に
鑑みなされたものであって、本発明の目的は、データ構
造が一意に定まっていないＸＭＬデータをデータベース
に格納し、複雑な間合わせを高速に実行することができ
るＸＭＬデータの検索システムを提供することである。
【０００８】
【課題を解決するための手段】図１は本発明の基本構成
を示す図である。同図に示すように、本発明のシステム
は、エレメントを中間ノードとし、エレメント値と属性
値を葉ノードとし、タグをリンクとする木構造で表現さ
れるＸＭＬで記述されたデータを検索するシステムにお
いて、ＸＭＬデータを格納する格納手段１を設け、該格
納手段１の関係データベースに、少なくとも中間ノード
の情報を格納するための中間ノードテーブル２と、リン
クの情報を格納するためのリンクテーブル３と、葉ノー
ドの情報を格納するための葉ノードテーブル４とを設け
る。そして、上記ＸＭＬの木構造で表現されたＸＭＬデ
ータをノード単位で分割し、上記テーブル２〜４に各ノ
ードとリンク情報を関係付けて格納する。ＸＭＬでは、
木構造を形成する中間ノードと、エレメントの値を持っ
ている葉ノードとでは、格納するために最適な格納構造
が異なるので、上記のようにそれぞれ最適化された別々
の専用テーブルに格納するのが望ましい。このように、
値を持つためのノードである葉ノードと木構造の情報を
持っためのノードである中間ノードを別々のテーブルに
格納することにより、値を格納するための格納スペース
を節約することが可能となる。各ノード間の接続情報を
保持する為のリンクも、リンクテーブル３に格納して持
っておく必要がある。また、属性情報を格納するための
属性テーブル５を別途設けてもよい。さらに、中間ノー
ドテーブル２に各ノードのルートからのフルパス情報を
ＩＤで記述し、パス用のＩＤと文字列の対応表をパスＩ
Ｄテーブル６として別に持つことにより、格納スペース
の節約と、検索の高速化を図ることができる。同様に、
リンクテーブル３のタグ名と属性ノードテーブルの属性
名をＩＤで記述し、これらラベルのＩＤと文字列の対応
表をラベルＩＤテーブル７として別に持つことによっ
て、格納スペースの節約と文字列検索の高速化を図るこ
とができる。また、リンクテーブル３の中に各子エレメ
ントがそのエレメント内で出現した順序の情報を付加
し、葉ノードテーブルの中に各エレメント値がそのエレ
メント内で出現した順序の情報を付加することにより、
元のＸＭＬ文書の復元が可能となる。
を示す図である。同図に示すように、本発明のシステム
は、エレメントを中間ノードとし、エレメント値と属性
値を葉ノードとし、タグをリンクとする木構造で表現さ
れるＸＭＬで記述されたデータを検索するシステムにお
いて、ＸＭＬデータを格納する格納手段１を設け、該格
納手段１の関係データベースに、少なくとも中間ノード
の情報を格納するための中間ノードテーブル２と、リン
クの情報を格納するためのリンクテーブル３と、葉ノー
ドの情報を格納するための葉ノードテーブル４とを設け
る。そして、上記ＸＭＬの木構造で表現されたＸＭＬデ
ータをノード単位で分割し、上記テーブル２〜４に各ノ
ードとリンク情報を関係付けて格納する。ＸＭＬでは、
木構造を形成する中間ノードと、エレメントの値を持っ
ている葉ノードとでは、格納するために最適な格納構造
が異なるので、上記のようにそれぞれ最適化された別々
の専用テーブルに格納するのが望ましい。このように、
値を持つためのノードである葉ノードと木構造の情報を
持っためのノードである中間ノードを別々のテーブルに
格納することにより、値を格納するための格納スペース
を節約することが可能となる。各ノード間の接続情報を
保持する為のリンクも、リンクテーブル３に格納して持
っておく必要がある。また、属性情報を格納するための
属性テーブル５を別途設けてもよい。さらに、中間ノー
ドテーブル２に各ノードのルートからのフルパス情報を
ＩＤで記述し、パス用のＩＤと文字列の対応表をパスＩ
Ｄテーブル６として別に持つことにより、格納スペース
の節約と、検索の高速化を図ることができる。同様に、
リンクテーブル３のタグ名と属性ノードテーブルの属性
名をＩＤで記述し、これらラベルのＩＤと文字列の対応
表をラベルＩＤテーブル７として別に持つことによっ
て、格納スペースの節約と文字列検索の高速化を図るこ
とができる。また、リンクテーブル３の中に各子エレメ
ントがそのエレメント内で出現した順序の情報を付加
し、葉ノードテーブルの中に各エレメント値がそのエレ
メント内で出現した順序の情報を付加することにより、
元のＸＭＬ文書の復元が可能となる。
【０００９】本発明では、ＸＭＬの木構造をそのまま格
納手段１に格納するので、ＤＴＤ無しのＸＭＬデータや
半構造のＸＭＬデータも格納できる。また、ＸＭＬの木
構造を全てデータベース上に格納しているので、木構造
の全ての情報を検索に利用することができる。しかしこ
れだけでは問い合わせが行なわれたときに、ノード単位
に分割して格納されているＸＭＬデータの木構造を再結
合するのに時間がかかり、問い合わせの実行時間が遅く
なる。そこで本発明では、上記のテーブル２〜７に、Ｘ
ＭＬデータへの問い合わせパターンを考慮してインデッ
クス８を張る。これにより、ＸＭＬの木構造を辿るよう
な複雑な問い合わせの実行を高速に行なうことを可能と
なる。上記ＸＭＬデータを検索するには、例えばＸＭＬ
データ検索言語により、問い合わせを行う。これにより
問い合わせ処理手段９は、問い合わせ文の構文チェック
を行い問い合わせのための構文木を生成し、最適な実行
プランを生成する。この実行プランは、木構造検索用の
関数セットで記述される。この実行プランにより、上記
インデックス８を用いて木構造を辿る問い合わせを実行
し、要求された検索結果を出力する。
納手段１に格納するので、ＤＴＤ無しのＸＭＬデータや
半構造のＸＭＬデータも格納できる。また、ＸＭＬの木
構造を全てデータベース上に格納しているので、木構造
の全ての情報を検索に利用することができる。しかしこ
れだけでは問い合わせが行なわれたときに、ノード単位
に分割して格納されているＸＭＬデータの木構造を再結
合するのに時間がかかり、問い合わせの実行時間が遅く
なる。そこで本発明では、上記のテーブル２〜７に、Ｘ
ＭＬデータへの問い合わせパターンを考慮してインデッ
クス８を張る。これにより、ＸＭＬの木構造を辿るよう
な複雑な問い合わせの実行を高速に行なうことを可能と
なる。上記ＸＭＬデータを検索するには、例えばＸＭＬ
データ検索言語により、問い合わせを行う。これにより
問い合わせ処理手段９は、問い合わせ文の構文チェック
を行い問い合わせのための構文木を生成し、最適な実行
プランを生成する。この実行プランは、木構造検索用の
関数セットで記述される。この実行プランにより、上記
インデックス８を用いて木構造を辿る問い合わせを実行
し、要求された検索結果を出力する。
【００１０】 本発明においては、次のように構成する
こともできる。 （１) テーブルに関係データベースの制約の機能を適用
することによって、ＸＭＬの構文規則をチェックする。 （２) リンクテーブルの中に、各エレメントの同ラベル
を持つ兄弟エレメント中での出現順序の情報を付加し、
各ラベルの出現順序を指定した問い合わせの実行を可能
とする。 （３) リンクテーブルにリンクの両節点の情報だけでな
くタグ名の情報も待つことによって、タグ名を指定して
リンクを辿る問い合わせを高速に実行する。 （４) 属性テーブルの中の属性ノードの接続先をリンク
ではなくて中間ノードにすることによって、属性を条件
にして木構造を辿る問い合わせを実行する際のテーブル
検索回数を削減し、問い合わせの高速実行を可能とす
る。 （５) 中間ノードテーブルのパスＩＤによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値をパスＩＤとノードＩＤの組とする
ことによってキー値の重複を無くす。 （６) 中間ノードテーブルの文書ＩＤによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値を文書ＩＤとノードＩＤの組とする
ことによってキー値の重複を無くす。
こともできる。 （１) テーブルに関係データベースの制約の機能を適用
することによって、ＸＭＬの構文規則をチェックする。 （２) リンクテーブルの中に、各エレメントの同ラベル
を持つ兄弟エレメント中での出現順序の情報を付加し、
各ラベルの出現順序を指定した問い合わせの実行を可能
とする。 （３) リンクテーブルにリンクの両節点の情報だけでな
くタグ名の情報も待つことによって、タグ名を指定して
リンクを辿る問い合わせを高速に実行する。 （４) 属性テーブルの中の属性ノードの接続先をリンク
ではなくて中間ノードにすることによって、属性を条件
にして木構造を辿る問い合わせを実行する際のテーブル
検索回数を削減し、問い合わせの高速実行を可能とす
る。 （５) 中間ノードテーブルのパスＩＤによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値をパスＩＤとノードＩＤの組とする
ことによってキー値の重複を無くす。 （６) 中間ノードテーブルの文書ＩＤによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値を文書ＩＤとノードＩＤの組とする
ことによってキー値の重複を無くす。
【００１１】
【発明の実施の形態】以下、本発明の実施の形態につい
て説明する。 （１) システム構成 図２は本発明の実施例のシステムの構成を示す図であ
る。同図に示すように、本実施例のシステムは大きくわ
けて、ＸＭＬデータ格納部１１、ＸＭＬデータ格納部１
１にＸＭＬデータを挿入するためのＸＭＬデータ挿入モ
ジュール１２、格納されたＸＭＬデータへの問い合わせ
を処理する問い合わせ処理エンジン部１３から構成され
る。ＸＭＬデータは、ＸＭＬデータ挿入モジュール１２
によって、ＸＭＬデータ格納部１１に挿入される。ＸＭ
Ｌデータ挿入モジュール１２は、ＸＭＬパーザ１２ａと
ローダー１２ｂから成り、ＸＭＬバーザ１２ａは入力さ
れたＸＭＬデータを構文解析し、ＸＭＬデータの木構造
を、ＸＭＬデータ格納部１１に格納できるようにノード
単位に分解する。また、ローダー１２ｂは、そのノード
単位に分解された木構造をＸＭＬデータ格納部１１のテ
ーブルに挿入する。
て説明する。 （１) システム構成 図２は本発明の実施例のシステムの構成を示す図であ
る。同図に示すように、本実施例のシステムは大きくわ
けて、ＸＭＬデータ格納部１１、ＸＭＬデータ格納部１
１にＸＭＬデータを挿入するためのＸＭＬデータ挿入モ
ジュール１２、格納されたＸＭＬデータへの問い合わせ
を処理する問い合わせ処理エンジン部１３から構成され
る。ＸＭＬデータは、ＸＭＬデータ挿入モジュール１２
によって、ＸＭＬデータ格納部１１に挿入される。ＸＭ
Ｌデータ挿入モジュール１２は、ＸＭＬパーザ１２ａと
ローダー１２ｂから成り、ＸＭＬバーザ１２ａは入力さ
れたＸＭＬデータを構文解析し、ＸＭＬデータの木構造
を、ＸＭＬデータ格納部１１に格納できるようにノード
単位に分解する。また、ローダー１２ｂは、そのノード
単位に分解された木構造をＸＭＬデータ格納部１１のテ
ーブルに挿入する。
【００１２】図３に上記ＸＭＬデータの格納処理を示す
フローチャートを示す。本実施例においてＸＭＬデータ
の格納処理は次のように行われる。まず、ステップＳ１
において、ＸＭＬファイルを読み込む。ステップＳ２に
おいて、ＸＭＬパーザにより、入力ファイルの構文解析
を行う。解析が成功した場合には、ステップＳ３に行
き、ＸＭＬパーザが解析結果として、ＸＭＬの木構造の
ノード情報とリンク情報を中間形式としてファイル出力
する。また、解析が成功しない場合には、構文解析失敗
としてエラー出力し処理を終了する。ステップＳ４にお
いて、生成された中間形式ファイルを読み込み、ステッ
プＳ５において、読み込んだＸＭＬデータをローダによ
って関係データベースの各テーブルに挿入し、処理を終
了する。また、上記挿入が成功しない場合には、データ
挿入失敗としてエラー出力をして処理を終了する。
フローチャートを示す。本実施例においてＸＭＬデータ
の格納処理は次のように行われる。まず、ステップＳ１
において、ＸＭＬファイルを読み込む。ステップＳ２に
おいて、ＸＭＬパーザにより、入力ファイルの構文解析
を行う。解析が成功した場合には、ステップＳ３に行
き、ＸＭＬパーザが解析結果として、ＸＭＬの木構造の
ノード情報とリンク情報を中間形式としてファイル出力
する。また、解析が成功しない場合には、構文解析失敗
としてエラー出力し処理を終了する。ステップＳ４にお
いて、生成された中間形式ファイルを読み込み、ステッ
プＳ５において、読み込んだＸＭＬデータをローダによ
って関係データベースの各テーブルに挿入し、処理を終
了する。また、上記挿入が成功しない場合には、データ
挿入失敗としてエラー出力をして処理を終了する。
【００１３】格納されたＸＭＬデータに対する問い合わ
せは、ＸＭＬデータ問い合わせ言語で行なわれ、その問
い合わせは問い合わせ処理エンジン１３で処理される。
問い合わせ処理エンジン１３は、問い合わせ言語のパー
ザ１３ａ、問い合わせ最適化エンジン１３ｂ、木構造検
索用ＡＰＩ（アプリケーション・プログラミング・イン
タフェース) １３ｃから成る。問い合わせ言語のパーザ
１３ａは、入力された問い合わせ文の構文チェックを行
い問い合わせのための構文木を生成する。問い合わせ最
適化エンジン１３ｂは、上記構文木を基に、最適な実行
プランを生成する。この実行プランは、木構造検索用Ａ
ＰＩ１３ｃの関数セットで記述される。木構造検索用Ａ
ＰＩ１３ｃは、ＸＭＬデータ格納部１１とのインタフェ
ースで、ＸＭＬの木構造上での基本的な検索を行なう関
数のセットである。
せは、ＸＭＬデータ問い合わせ言語で行なわれ、その問
い合わせは問い合わせ処理エンジン１３で処理される。
問い合わせ処理エンジン１３は、問い合わせ言語のパー
ザ１３ａ、問い合わせ最適化エンジン１３ｂ、木構造検
索用ＡＰＩ（アプリケーション・プログラミング・イン
タフェース) １３ｃから成る。問い合わせ言語のパーザ
１３ａは、入力された問い合わせ文の構文チェックを行
い問い合わせのための構文木を生成する。問い合わせ最
適化エンジン１３ｂは、上記構文木を基に、最適な実行
プランを生成する。この実行プランは、木構造検索用Ａ
ＰＩ１３ｃの関数セットで記述される。木構造検索用Ａ
ＰＩ１３ｃは、ＸＭＬデータ格納部１１とのインタフェ
ースで、ＸＭＬの木構造上での基本的な検索を行なう関
数のセットである。
【００１４】次に、上記システムにおける各部の構成に
ついてさらに詳細に説明する。 （１) テーブル構成 まず、上記ＸＭＬデータ格納部１１に格納されるテーブ
ルの構成について説明する。ＸＭＬデータを木構造で表
現する方法はいくつかあるが、本実施例では図４に示す
木構造表現を想定している。図４は、前記図８に示した
ＸＭＬデータを木構造で表現したものである。この木構
造表現において、丸い中間ノードはエレメントを表して
おり、ノードの親子関係がエレメントの包含関係を表し
ている。
ついてさらに詳細に説明する。 （１) テーブル構成 まず、上記ＸＭＬデータ格納部１１に格納されるテーブ
ルの構成について説明する。ＸＭＬデータを木構造で表
現する方法はいくつかあるが、本実施例では図４に示す
木構造表現を想定している。図４は、前記図８に示した
ＸＭＬデータを木構造で表現したものである。この木構
造表現において、丸い中間ノードはエレメントを表して
おり、ノードの親子関係がエレメントの包含関係を表し
ている。
【００１５】また、ノードの丸の中の数字はノードＩＤ
を表している。ノードとノードを結ぶリンク（枝) はタ
グを表しており、リンクの横に書かれている文字列はタ
グ名を表している。三角の葉ノードはエレメントの値を
表し、四角い葉ノードはタグに付けられた属性(Atrriｂ
ute)を表している。値を持つのはこの２つの葉ノードだ
けである。ノードを分割してデータベースに格納すると
きに、ノードの情報だけをデータベースのテーブルに格
納したのでは、木構造のノード間の繋がり、つまりリン
クの情報が欠落してしまう。そこで、リンクの情報はリ
ンクの情報としてそれを格納する専用のテーブルを用意
する。またノードも、中間ノードと、エレメント値の葉
ノード、属性の葉ノードとは最適な格納構造が異なるの
で、別々のテーブルに格納する必要がある。
を表している。ノードとノードを結ぶリンク（枝) はタ
グを表しており、リンクの横に書かれている文字列はタ
グ名を表している。三角の葉ノードはエレメントの値を
表し、四角い葉ノードはタグに付けられた属性(Atrriｂ
ute)を表している。値を持つのはこの２つの葉ノードだ
けである。ノードを分割してデータベースに格納すると
きに、ノードの情報だけをデータベースのテーブルに格
納したのでは、木構造のノード間の繋がり、つまりリン
クの情報が欠落してしまう。そこで、リンクの情報はリ
ンクの情報としてそれを格納する専用のテーブルを用意
する。またノードも、中間ノードと、エレメント値の葉
ノード、属性の葉ノードとは最適な格納構造が異なるの
で、別々のテーブルに格納する必要がある。
【００１６】本実施例で使用するテーブルは、全部で次
の６つである。 中間ノードテーブル これは中間ノードの情報を格納するテーブルである。ノ
ードＩＤ(id)の他に、そのノードが含まれている文書の
文書ＩＤ(docid) 、そのノードまでのルートからのフル
パスのＩＤ(pathid)をカラムとして持っている。 リンクテーブル これはノード間のリンクを格納するテーブルである。ノ
ードＩＤ(id)、リンクのラベル（タグ名) のＩＤ(lａbe
lid)、子ノードのノードＩＤ(child) 、その子ノードの
全兄弟ノード中での出現順序(tord:total order)、その
子ノードの同ラベルを持つ兄弟ノード中での出現順序(p
ord:partial order)をカラムとして持っている。上記の
ように、リンクテーブル中にラベル（タグ名) のＩＤ(l
ａbelid)を付加することによりタグ名を指定してリンク
を辿る問い合わせを高速に実行することが可能となる。
の６つである。 中間ノードテーブル これは中間ノードの情報を格納するテーブルである。ノ
ードＩＤ(id)の他に、そのノードが含まれている文書の
文書ＩＤ(docid) 、そのノードまでのルートからのフル
パスのＩＤ(pathid)をカラムとして持っている。 リンクテーブル これはノード間のリンクを格納するテーブルである。ノ
ードＩＤ(id)、リンクのラベル（タグ名) のＩＤ(lａbe
lid)、子ノードのノードＩＤ(child) 、その子ノードの
全兄弟ノード中での出現順序(tord:total order)、その
子ノードの同ラベルを持つ兄弟ノード中での出現順序(p
ord:partial order)をカラムとして持っている。上記の
ように、リンクテーブル中にラベル（タグ名) のＩＤ(l
ａbelid)を付加することによりタグ名を指定してリンク
を辿る問い合わせを高速に実行することが可能となる。
【００１７】葉ノードテーブル
これはエレメント値の葉ノードを格納するテーブルであ
る。そのエレメントにあたる中間ノードのノードＩＤ(i
d)の他に、エレメントの値(value) と、そのエレメント
中でその値が出現した順序(order) をカラムとして持っ
ている。このように、値を持つための葉ノードテーブル
を、前記中間ノードテーブルとは別に設けることによ
り、値を格納するスペースを節約することができる。
る。そのエレメントにあたる中間ノードのノードＩＤ(i
d)の他に、エレメントの値(value) と、そのエレメント
中でその値が出現した順序(order) をカラムとして持っ
ている。このように、値を持つための葉ノードテーブル
を、前記中間ノードテーブルとは別に設けることによ
り、値を格納するスペースを節約することができる。
【００１８】属性ノードテーブル
これはタグにつけられた属性（例えば図８における<boo
k year="1995">におけるyear）を格納するテーブルであ
る。そのタグが含まれるエレメントにあたる中間ノード
のノードＩＤ(id)の他に、属性名のＩＤ(labelid) 、属
性値(Attvalue)をカラムとして待つ。なお、属性テーブ
ルに関係データベースの制約機能を用いて、(id,labeli
d)の組がユニークという制約をかけておくことによっ
て、「同一のタグ内では同一の属性名は出現してはなら
ない」というＸＭＬの属性に関する構文規則をチェック
することができる。また、本実施例で想定している木構
造表現では、ＸＭＬのタグが木構造のリンクに相当する
ので、ＸＭＬのタグに付けられる属性は本来ならばリン
クに付くべきである。しかし、図４では、属性はリンク
に対してではなく、その下のノードに付いている。これ
は、検索時のテーブル参照の回数を少なくするためであ
る。すなわち、属性を条件として木構造を辿る問い合わ
せを実行する際のテーブル検索回数を削減し、問い合わ
せの高速化を図ることが可能となる。
k year="1995">におけるyear）を格納するテーブルであ
る。そのタグが含まれるエレメントにあたる中間ノード
のノードＩＤ(id)の他に、属性名のＩＤ(labelid) 、属
性値(Attvalue)をカラムとして待つ。なお、属性テーブ
ルに関係データベースの制約機能を用いて、(id,labeli
d)の組がユニークという制約をかけておくことによっ
て、「同一のタグ内では同一の属性名は出現してはなら
ない」というＸＭＬの属性に関する構文規則をチェック
することができる。また、本実施例で想定している木構
造表現では、ＸＭＬのタグが木構造のリンクに相当する
ので、ＸＭＬのタグに付けられる属性は本来ならばリン
クに付くべきである。しかし、図４では、属性はリンク
に対してではなく、その下のノードに付いている。これ
は、検索時のテーブル参照の回数を少なくするためであ
る。すなわち、属性を条件として木構造を辿る問い合わ
せを実行する際のテーブル検索回数を削減し、問い合わ
せの高速化を図ることが可能となる。
【００１９】パスＩＤテーブル
これはパスＩＤとパスの文字列の対応表である。パスの
文字列を中間ノードテーブルに直接書き込まないでこの
ように別に持っているのは、スペースの節約の為もある
が、パス名の文字列マッチングを含む検索が行なわれた
ときに、検索対象が少なくてすみ、検索が高速化できる
からでもある。 ラベルＩＤテーブル これはラベルＩＤとラベルの文字列の対応表である。こ
のように、リンクテーブルのタグ名と、属性ノードテー
ブルの属性名をＩＤで記述し、このラベルのＩＤと文字
列の対応表をラベルＩＤテーブルとして別に持つことに
より、パスＩＤテーブルと同様、格納スペースの節約
と、検索の高速化を図ることができる。
文字列を中間ノードテーブルに直接書き込まないでこの
ように別に持っているのは、スペースの節約の為もある
が、パス名の文字列マッチングを含む検索が行なわれた
ときに、検索対象が少なくてすみ、検索が高速化できる
からでもある。 ラベルＩＤテーブル これはラベルＩＤとラベルの文字列の対応表である。こ
のように、リンクテーブルのタグ名と、属性ノードテー
ブルの属性名をＩＤで記述し、このラベルのＩＤと文字
列の対応表をラベルＩＤテーブルとして別に持つことに
より、パスＩＤテーブルと同様、格納スペースの節約
と、検索の高速化を図ることができる。
【００２０】また、上記のように、リンクテーブル中
に、子ノードの全兄弟ノード中での出現順序(tord:tota
l order)の情報を付加し、また、葉ノードテーブル中
に、各エレメント値がそのエレメント内で出現した順序
(order) の情報を付加することに、ＸＭＬデータ格納部
１１に格納されるノード単位に分解されたＸＭＬデータ
から、元のＸＭＬ文書を復元することが可能となる。例
えば、「今日は <天気> 晴れ</天気> だった。○○は <
場所> デパート</場所> へでかけた。」のようにタグで
区切られた文章を復元することも可能になる。また、リ
ンクテーブル中に、各エレメントの同ラベルを持つ兄弟
ノード中での出現順序(pord:partial order)の情報を付
加することにより、各ラベルの出現順序を指定した問い
合わせを高速に実行することが可能となる。
に、子ノードの全兄弟ノード中での出現順序(tord:tota
l order)の情報を付加し、また、葉ノードテーブル中
に、各エレメント値がそのエレメント内で出現した順序
(order) の情報を付加することに、ＸＭＬデータ格納部
１１に格納されるノード単位に分解されたＸＭＬデータ
から、元のＸＭＬ文書を復元することが可能となる。例
えば、「今日は <天気> 晴れ</天気> だった。○○は <
場所> デパート</場所> へでかけた。」のようにタグで
区切られた文章を復元することも可能になる。また、リ
ンクテーブル中に、各エレメントの同ラベルを持つ兄弟
ノード中での出現順序(pord:partial order)の情報を付
加することにより、各ラベルの出現順序を指定した問い
合わせを高速に実行することが可能となる。
【００２１】一例として、図８のサンプルＸＭＬデータ
（図４の木構造表現) を上記のテーブル群で格納した様
子を図５、図６に示す。図５は中間ノードテーブル、リ
ンクテーブルの例を示す図である。中間ノードテーブル
において、例えば、第１行目のid（＝５) は図４におい
て" ５" と記されたノードを示し、そのノードが含まれ
ている文書の文書ＩＤ(docid) は１である。また、その
ノードまでのルートからのフルパスのＩＤ(pathid)は１
であり、このＩＤに対応したpathは、"bib.book.puｂli
sher.name"である。また、リンクテーブルにおいて、例
えば１行目のid（＝４）は図４において、" ４" と記さ
れたノードを示し、そのlaｂelidは５であり、このlabe
lid に対応するlabel は"name"である。また、その出現
順序を示すtord,pord はそれぞれ" ０"," ０" であり、
子ノードは、図４で "５" と記されたノードである。
（図４の木構造表現) を上記のテーブル群で格納した様
子を図５、図６に示す。図５は中間ノードテーブル、リ
ンクテーブルの例を示す図である。中間ノードテーブル
において、例えば、第１行目のid（＝５) は図４におい
て" ５" と記されたノードを示し、そのノードが含まれ
ている文書の文書ＩＤ(docid) は１である。また、その
ノードまでのルートからのフルパスのＩＤ(pathid)は１
であり、このＩＤに対応したpathは、"bib.book.puｂli
sher.name"である。また、リンクテーブルにおいて、例
えば１行目のid（＝４）は図４において、" ４" と記さ
れたノードを示し、そのlaｂelidは５であり、このlabe
lid に対応するlabel は"name"である。また、その出現
順序を示すtord,pord はそれぞれ" ０"," ０" であり、
子ノードは、図４で "５" と記されたノードである。
【００２２】図６は葉ノードテーブル、属性ノードテー
ブル、パスＩＤテーブル、ラベルＩＤテーブルの例を示
す図である。葉ノードテーブルにおいて、例えば第１行
目のid（＝５) は図４において、"５" と記されたノー
ドを示し、そのorder は" ０" 、またその葉ノードの値
(vａlue)は"Addison-Wesley"である。属性ノードテーブ
ルにおいて、例えば第１行目のid（＝３) は図４におい
て、”３" と記されたノードを示し、そのlabelid は３
（"year"に対応) 、その属性値（ａttvalue ) は "１９
９５”である。また、パスＩＤテーブル、ラベルＩＤテ
ーブルにはそれぞれ、上記各テーブル中のpathid、labe
lid に対応したパスの文字列、ラベルの文字列が格納さ
れ、例えば、pathid＝”１" に対応した文字列は前記し
たように" ｂib.book.puｂlisher.name"であり、また、
例えばlabelid ＝”１" に対応した文字列は" bib"であ
る。
ブル、パスＩＤテーブル、ラベルＩＤテーブルの例を示
す図である。葉ノードテーブルにおいて、例えば第１行
目のid（＝５) は図４において、"５" と記されたノー
ドを示し、そのorder は" ０" 、またその葉ノードの値
(vａlue)は"Addison-Wesley"である。属性ノードテーブ
ルにおいて、例えば第１行目のid（＝３) は図４におい
て、”３" と記されたノードを示し、そのlabelid は３
（"year"に対応) 、その属性値（ａttvalue ) は "１９
９５”である。また、パスＩＤテーブル、ラベルＩＤテ
ーブルにはそれぞれ、上記各テーブル中のpathid、labe
lid に対応したパスの文字列、ラベルの文字列が格納さ
れ、例えば、pathid＝”１" に対応した文字列は前記し
たように" ｂib.book.puｂlisher.name"であり、また、
例えばlabelid ＝”１" に対応した文字列は" bib"であ
る。
【００２３】（２) インデックスの構成
本実施例においては、本来連結されていたはずの木構造
のノードが、前記したように１つ１つに分割されて関係
データベースのテーブルに格納されている。このため
に、木構造を辿る問い合わせが行なわれた場合、問い合
わせで辿る部分のリンクを連結し直すためにジョイン操
作が行なわれる。このジョイン操作の速度は全体の検索
速度に大きく影響するので、ジョイン操作を高速に行な
えるようにインデックスを効果的に張っておく必要があ
る。また、問い合わせが行なわれる場合、検索条件とし
て指定されるのは、エレメントの値、属性、パス、出現
順序などである。それらの検索も高速に行なう必要があ
るので、そこにもインデックスを用意しておく必要があ
る。
のノードが、前記したように１つ１つに分割されて関係
データベースのテーブルに格納されている。このため
に、木構造を辿る問い合わせが行なわれた場合、問い合
わせで辿る部分のリンクを連結し直すためにジョイン操
作が行なわれる。このジョイン操作の速度は全体の検索
速度に大きく影響するので、ジョイン操作を高速に行な
えるようにインデックスを効果的に張っておく必要があ
る。また、問い合わせが行なわれる場合、検索条件とし
て指定されるのは、エレメントの値、属性、パス、出現
順序などである。それらの検索も高速に行なう必要があ
るので、そこにもインデックスを用意しておく必要があ
る。
【００２４】図７に、上記図５、図６に示したテーブル
に張ったインデックスの一覧を示す。このインデックス
は B+ -tree で張ってあり、キーが複数の属性の組から
なるインデックスは、その組の先頭からの部分的な属性
の組で検索に用いることもできる。なお中間ノードテー
ブルに張ってあるインデックスでキーが(pathid,id) の
ものは、あるパスに該当する全てのノードを検索してく
るときに使用するものである。このインデックスのキー
は、一見pathid単独で構わないように思われるかもしれ
ない。しかしキーをpathidだけにすると、同じキー値を
持つエントリが多量に発生して、B + -tree インデック
スが機能しなくなる。上記のようにキー値をパスＩＤ(p
athid)とノードのＩＤ(id)の組とすることにより、キー
値の重複を無くすことができ、B + -tree の検索を高速
に行うことができる。また、中間ノードテーブルに張っ
てあるインデックスでキーが(docid,id)も同様であり、
文書ＩＤ(docid) とノードのＩＤ(id)の組とすることに
より、キー値の重複を無くすことができ、B + -tree の
検索を高速に行うことができる。
に張ったインデックスの一覧を示す。このインデックス
は B+ -tree で張ってあり、キーが複数の属性の組から
なるインデックスは、その組の先頭からの部分的な属性
の組で検索に用いることもできる。なお中間ノードテー
ブルに張ってあるインデックスでキーが(pathid,id) の
ものは、あるパスに該当する全てのノードを検索してく
るときに使用するものである。このインデックスのキー
は、一見pathid単独で構わないように思われるかもしれ
ない。しかしキーをpathidだけにすると、同じキー値を
持つエントリが多量に発生して、B + -tree インデック
スが機能しなくなる。上記のようにキー値をパスＩＤ(p
athid)とノードのＩＤ(id)の組とすることにより、キー
値の重複を無くすことができ、B + -tree の検索を高速
に行うことができる。また、中間ノードテーブルに張っ
てあるインデックスでキーが(docid,id)も同様であり、
文書ＩＤ(docid) とノードのＩＤ(id)の組とすることに
より、キー値の重複を無くすことができ、B + -tree の
検索を高速に行うことができる。
【００２５】（３) 問い合わせの実行
前記したように、格納されたＸＭＬデータに対する問い
合わせは、例えばＸＭＬデータの問い合わせ言語で行な
われる。ＸＭＬデータのための検索言語の一つとして検
索言語ＸＱＬがある。ＸＱＬによる問い合わせ文を、例
により簡単に説明する。
合わせは、例えばＸＭＬデータの問い合わせ言語で行な
われる。ＸＭＬデータのための検索言語の一つとして検
索言語ＸＱＬがある。ＸＱＬによる問い合わせ文を、例
により簡単に説明する。
【００２６】
SELECT result:<$book.title>
FROM book: bib.book
WHERE $book.author.lastname="Darwen";
この問い合わせの意味は「bib.book.author.lastnameが
Darwenであるようなbib.bookについて、bib.book.title
を検索結果として得たい」という意味である。
Darwenであるようなbib.bookについて、bib.book.title
を検索結果として得たい」という意味である。
【００２７】上記に示すように、問い合わせ文は大き
く、SELECT、FROM、WHERE の３つの部分に別れている。
SELECTの部分では検索結果として得たいエレメントのプ
ロジェクションを指定する。FROMの部分では検索の対象
となるエレメントを指定している。WHERE の部分では検
索の条件のセレクションを指定する。上記のような問い
合わせは前記したように、問い合わせ処理エンジン１３
で処理される。問い合わせ処理エンジン１３では、上記
のような問い合わせ文の構文チェックを行い問い合わせ
のための構文木を生成する。そして、該構文木を基に、
最適な実行プランを生成する。この実行プランは、木構
造検索用の関数セットで記述される。
く、SELECT、FROM、WHERE の３つの部分に別れている。
SELECTの部分では検索結果として得たいエレメントのプ
ロジェクションを指定する。FROMの部分では検索の対象
となるエレメントを指定している。WHERE の部分では検
索の条件のセレクションを指定する。上記のような問い
合わせは前記したように、問い合わせ処理エンジン１３
で処理される。問い合わせ処理エンジン１３では、上記
のような問い合わせ文の構文チェックを行い問い合わせ
のための構文木を生成する。そして、該構文木を基に、
最適な実行プランを生成する。この実行プランは、木構
造検索用の関数セットで記述される。
【００２８】次に、上記ＸＭＬデータに対する問い合わ
せ処理が、どのように行なわれるかを説明する。ここで
は、図８のサンプルＸＭＬデータを、ＸＭＬデータ格納
部１１に格納し、前述した図５、図６に示したテーブル
に挿入した場合を例として、上記のように「著者がDarw
enである本のタイトルを求めよ」という問い合わせを行
なった場合について説明する。この場合のテーブル検索
は、次のように行われる。なお、下記１. 〜１０. の処
理は、上記木構造検索用の関数により実行される。
せ処理が、どのように行なわれるかを説明する。ここで
は、図８のサンプルＸＭＬデータを、ＸＭＬデータ格納
部１１に格納し、前述した図５、図６に示したテーブル
に挿入した場合を例として、上記のように「著者がDarw
enである本のタイトルを求めよ」という問い合わせを行
なった場合について説明する。この場合のテーブル検索
は、次のように行われる。なお、下記１. 〜１０. の処
理は、上記木構造検索用の関数により実行される。
【００２９】１. 葉ノードテーブルを検索して、値が
“Darwen" であるノードのノードＩＤ（＝１６) を得
る。 ２. パスＩＤテーブルを検索して、パス"bib.book.auth
or.lastname " のパスＩＤ（＝４) を得る。 ３. 中間ノードテーブルを上記１. で得られたノードＩ
Ｄ（＝１６) で検索して、得られたパスＩＤ（＝４) が
上記２. で得られたパスＩＤ（＝４) と一致することを
確認する。 ４. ラベルＩＤテーブルを検索して、ラベル"lastname"
のラベルＩＤ（＝８) を得る。 ５. リンクテーブルを検索して、上記１. で得られたノ
ードＩＤ（＝１６) と上記４. で得られたラベルＩＤ
（＝８) から、親ノードのノードＩＤ（＝１５) を得
る。 ６. ラベルＩＤテーブルを検索して、ラベル" author "
のラベルＩＤ（＝７) を得る。 ７. リンクテーブルを検索して、上記５. で得られたノ
ードＩＤ（＝１５) と上記６. で得られたラベルＩＤ
（＝７) から、親ノードのノードＩＤ（＝９）を得る。 ８. ラベルＩＤテーブルを検索して、ラベル"title" の
ラベルＩＤ（＝６) を得る。 ９. リンクテーブルを検索して上記７. で得られたノー
ドＩＤ（＝９) と上記８. で得られたラベルＩＤ（＝
６) から、子ノードのノードＩＤ（＝１２) を得る。 １０. 葉ノードテーブルを検索して、上記９. で得られ
たノードＩＤ（＝１２)から、そのノードの値("Foundat
ion for Object/Relational Database") を得る。以上
のようにして得られた検索結果は、問い合わせ処理エン
ジン１３を介して出力され、ユーザに提示される。
“Darwen" であるノードのノードＩＤ（＝１６) を得
る。 ２. パスＩＤテーブルを検索して、パス"bib.book.auth
or.lastname " のパスＩＤ（＝４) を得る。 ３. 中間ノードテーブルを上記１. で得られたノードＩ
Ｄ（＝１６) で検索して、得られたパスＩＤ（＝４) が
上記２. で得られたパスＩＤ（＝４) と一致することを
確認する。 ４. ラベルＩＤテーブルを検索して、ラベル"lastname"
のラベルＩＤ（＝８) を得る。 ５. リンクテーブルを検索して、上記１. で得られたノ
ードＩＤ（＝１６) と上記４. で得られたラベルＩＤ
（＝８) から、親ノードのノードＩＤ（＝１５) を得
る。 ６. ラベルＩＤテーブルを検索して、ラベル" author "
のラベルＩＤ（＝７) を得る。 ７. リンクテーブルを検索して、上記５. で得られたノ
ードＩＤ（＝１５) と上記６. で得られたラベルＩＤ
（＝７) から、親ノードのノードＩＤ（＝９）を得る。 ８. ラベルＩＤテーブルを検索して、ラベル"title" の
ラベルＩＤ（＝６) を得る。 ９. リンクテーブルを検索して上記７. で得られたノー
ドＩＤ（＝９) と上記８. で得られたラベルＩＤ（＝
６) から、子ノードのノードＩＤ（＝１２) を得る。 １０. 葉ノードテーブルを検索して、上記９. で得られ
たノードＩＤ（＝１２)から、そのノードの値("Foundat
ion for Object/Relational Database") を得る。以上
のようにして得られた検索結果は、問い合わせ処理エン
ジン１３を介して出力され、ユーザに提示される。
【００３０】
【発明の効果】以上説明したように、本発明において
は、関係データベースに、中間ノードの情報を格納する
ための中間ノードテーブルと、リンクの情報を格納する
ためのリンクテーブルと、葉ノードの情報を格納するた
めの葉ノードテーブル等のテーブルを設け、ＸＭＬの木
構造をノードとリンクに分解して、上記テーブルに各ノ
ードとリンク情報を関係付けて格納し、上記テーブルを
参照して木構造を辿る問い合わせを実行し、ＸＭＬデー
タを検索するようにしたので、データ構造が一意に定ま
っていないＸＭＬデータに対する複雑な問い合わせを高
速に実行することができる。また、ＸＭＬの木構造をそ
のまま格納手段に格納するので、ＤＴＤ無しのＸＭＬデ
ータや半構造のＸＭＬデータも格納することができる。
さらにＸＭＬの木構造を全てデータベース上に格納して
いるので、木構造の全ての情報を検索に利用することが
できる。
は、関係データベースに、中間ノードの情報を格納する
ための中間ノードテーブルと、リンクの情報を格納する
ためのリンクテーブルと、葉ノードの情報を格納するた
めの葉ノードテーブル等のテーブルを設け、ＸＭＬの木
構造をノードとリンクに分解して、上記テーブルに各ノ
ードとリンク情報を関係付けて格納し、上記テーブルを
参照して木構造を辿る問い合わせを実行し、ＸＭＬデー
タを検索するようにしたので、データ構造が一意に定ま
っていないＸＭＬデータに対する複雑な問い合わせを高
速に実行することができる。また、ＸＭＬの木構造をそ
のまま格納手段に格納するので、ＤＴＤ無しのＸＭＬデ
ータや半構造のＸＭＬデータも格納することができる。
さらにＸＭＬの木構造を全てデータベース上に格納して
いるので、木構造の全ての情報を検索に利用することが
できる。
【図１】本発明の基本構成図である。
【図２】本発明の実施例のシステムの構成例を示す図で
ある。
ある。
【図３】本発明の実施例のシステムにおける格納処理フ
ローを示す図である。
ローを示す図である。
【図４】ＸＭＬデータの木構造表現の一例を示す図であ
る。
る。
【図５】本発明の実施例のテーブル構成の一例を示す図
（１) である。
（１) である。
【図６】本発明の実施例のテーブル構成の一例を示す図
（２) である。
（２) である。
【図７】本発明の実施例のイッデックス一覧を示す図で
ある。
ある。
【図８】ＸＭＬデータの一例を示す図である。
【図９】図８のＸＭＬデータをテーブルに格納した様子
を示す図である。
を示す図である。
１ ＸＭＬデータ格納格納手段
２ 中間ノードテーブル
３ リンクテーブル
４ 葉ノードテーブル
５ 属性テーブル
６ パスＩＤテーブル
７ ラベルＩＤテーブル
８ インデックス
９ 問い合わせ処理手段
１１ ＸＭＬデータ格納部
１２ ＸＭＬデータ挿入モジュール
１２ａ ＸＭＬパーザ
１２ｂ ローダ
１３ 問い合わせ処理エンジン部
１３ａ 問い合わせ言語のパーザ
１３ｂ 問い合わせ最適化エンジン
１３c 木構造検索用
フロントページの続き
(56)参考文献 志村壮是，吉川正俊，オブジェクト的
関係を用いたＸＭＬ文書の汎用的な格納
と検索，情報処理学会第58回（平成11年
前期）全国大会講演論文集（３），1999
年 ３月 ９日，第265〜266頁
田島敬史，半構造データのためのデー
タモデルと操作言語，情報処理学会論文
誌，1999年 ２月15日，第40巻，第ＳＩ
Ｇ３（ＴＯＤ１）号，第152〜170頁
(58)調査した分野(Int.Cl.7，ＤＢ名)
G06F 17/30
G06F 12/00
ＪＩＣＳＴファイル（ＪＯＩＳ)
Claims (3)
- 【請求項１】 エレメントを中間ノードとし、エレメン
ト値と属性値を葉ノードとし、タグをリンクとする木構
造で表現されるＸＭＬで記述されたデータを検索するシ
ステムであって、 上記システムは、ＸＭＬデータを格納する格納手段を備
え、該格納手段の関係データベースに、少なくとも中間
ノードの情報を格納するための中間ノードテーブルと、
リンクの情報を格納するためのリンクテーブルと、葉ノ
ードの情報を格納するための葉ノードテーブルとを設
け、中間ノードテーブルに、ノードＩＤによる検索を高速に
行なうためのインデックスと、テーブルの文書ＩＤによ
る検索を高速に行なうためのインデックスと、パスによ
る検索を高速に行なうためのインデックスを用意し、 リンクテーブルに、親ノードから子ノードを高速に検索
するためのインデックスと、子ノードから親ノードを高
速に検索するためのインデックスを用意し、 葉ノードテーブルに、ノードＩＤからそのノードの値を
得るためのインデックスと、ある値を持つノードを検索
するためのインデックスを用意し、 上記ＸＭＬの木構造をノードとリンクに分解して、上記
テーブルに各ノードとリンク情報を関係付けて格納し、
上記テーブルを参照して、上記インデックスを用いて木
構造を辿る問い合わせを実行し、ＸＭＬデータを検索す
ることを特徴とするＸＭＬデータ検索システム。 - 【請求項２】 関係データベースに、パスの文字列とパ
ス用のＩＤの対応表であるパスＩＤテーブルと、ラベル
の文字列とラベル用ＩＤの対応表であるラベルＩＤテー
ブルとを設け、パスＩＤテーブルに、パスの文字列に対応するバスＩＤ
を検索するためのインデックスを用意し、ラベルＩＤテ
ーブルに、ラベルの文字列に対応するラベルＩＤを検索
するためのインデックスを用意し、 上記インデックスを用いて木構造を辿る問い合わせを実
行することを特徴とする請求項１のＸＭＬデータ検索シ
ステム。 - 【請求項３】 リンクテーブルの中に各子エレメントが
そのエレメント内で出現した順序の情報を付加し、葉ノ
ードテーブルの中に各エレメント値がそのエレメント内
で出現した順序の情報を付加し、上記情報により元のＸ
ＭＬ文書の復元を可能としたことを特徴とする請求項１
または請求項２のＸＭＬデータ検索システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20390899A JP3492247B2 (ja) | 1999-07-16 | 1999-07-16 | Ｘｍｌデータ検索システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20390899A JP3492247B2 (ja) | 1999-07-16 | 1999-07-16 | Ｘｍｌデータ検索システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001034619A JP2001034619A (ja) | 2001-02-09 |
| JP3492247B2 true JP3492247B2 (ja) | 2004-02-03 |
Family
ID=16481701
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20390899A Expired - Fee Related JP3492247B2 (ja) | 1999-07-16 | 1999-07-16 | Ｘｍｌデータ検索システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3492247B2 (ja) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7305400B2 (en) | 2000-03-09 | 2007-12-04 | The Web Access, Inc. | Method and apparatus for performing a research task by interchangeably utilizing a multitude of search methodologies |
| KR20030006600A (ko) * | 2001-07-13 | 2003-01-23 | 다래정보통신 주식회사 | 프로그램 라이브러리 시스템 |
| AUPR645701A0 (en) | 2001-07-18 | 2001-08-09 | Tralee Investments Ltd | Database adapter |
| JP2003050811A (ja) | 2001-08-07 | 2003-02-21 | Sony Corp | 記録装置、記録方法、プログラム、記録媒体および撮像装置 |
| KR100831551B1 (ko) | 2001-09-28 | 2008-05-22 | 주식회사 케이티 | 관계형 데이터베이스를 이용해 문서를 저장, 검색 및 복구하는 장치 및 그 방법 |
| KR100484138B1 (ko) * | 2002-05-08 | 2005-04-18 | 삼성전자주식회사 | 관계형 데이터베이스에서 정규 경로식 질의를 처리하는ｘｍｌ 인덱싱 방법과 자료구조 |
| KR100521933B1 (ko) * | 2002-06-05 | 2005-10-13 | 엘지전자 주식회사 | 재기록 가능 기록매체의 편집 요약정보 관리방법 |
| US7322022B2 (en) | 2002-09-05 | 2008-01-22 | International Business Machines Corporation | Method for creating wrapper XML stored procedure |
| US7016915B2 (en) | 2002-12-28 | 2006-03-21 | International Business Machines Corporation | Method for processing XML queries over relational data and meta-data using a relational database system |
| US7003722B2 (en) | 2003-02-28 | 2006-02-21 | Microsoft Corporation | Method and system for converting a schema-based hierarchical data structure into a flat data structure |
| JP4247108B2 (ja) | 2003-12-25 | 2009-04-02 | 株式会社東芝 | 構造化文書検索方法、構造化文書検索装置、及びプログラム |
| JP4247135B2 (ja) | 2004-02-10 | 2009-04-02 | 株式会社東芝 | 構造化文書記憶方法、構造化文書記憶装置、構造化文書検索方法 |
| JP4724177B2 (ja) * | 2004-04-09 | 2011-07-13 | オラクル・インターナショナル・コーポレイション | Ｘｍｌデータにアクセスするためのインデックス |
| US7937413B2 (en) | 2004-05-04 | 2011-05-03 | International Business Machines Corporation | Self-adaptive prefix encoding for stable node identifiers |
| KR100666942B1 (ko) * | 2005-01-07 | 2007-01-11 | 삼성전자주식회사 | 관계형 ｄｂｍｓ를 이용한 ｘｍｌ 데이터 관리 방법 |
| US8543614B2 (en) | 2005-08-22 | 2013-09-24 | International Business Machines Corporation | Packing nodes into records to store XML XQuery data model and other hierarchically structured data |
| US7529726B2 (en) | 2005-08-22 | 2009-05-05 | International Business Machines Corporation | XML sub-document versioning method in XML databases using record storages |
| US8572125B2 (en) | 2005-08-22 | 2013-10-29 | International Business Machines Corporation | Scalable storage schemes for native XML column data of relational tables |
| KR100776823B1 (ko) | 2006-06-14 | 2007-11-19 | 고려대학교 산학협력단 | 단순 경로 질의에 대응하는 압축된 ｘｍｌ 스트림 생성방법, 단순 경로 질의에 대응하는 ｘｍｌ 스트림의 선택적수신 방법 및 그 장치 |
| JP4770694B2 (ja) * | 2006-10-18 | 2011-09-14 | セイコーエプソン株式会社 | デバイスと接続される装置、データ内を検索する方法、コンピュータプログラム、および、インデックスデータ |
| CN101965565A (zh) * | 2008-01-15 | 2011-02-02 | 国际商业机器公司 | 用于导航数据结构的方法和*** |
| JP5180772B2 (ja) * | 2008-10-03 | 2013-04-10 | 本田技研工業株式会社 | 穂の構造の解析方法および装置 |
| US8355900B2 (en) | 2008-10-03 | 2013-01-15 | Honda Motor Co. Ltd. | Method and apparatus for analyzing panicle structure |
| JP2010250449A (ja) * | 2009-04-13 | 2010-11-04 | Canon Inc | 情報処理装置、情報処理方法 |
| US9141727B2 (en) | 2010-05-14 | 2015-09-22 | Nec Corporation | Information search device, information search method, computer program, and data structure |
| US10579634B2 (en) * | 2012-08-30 | 2020-03-03 | Citus Data Bilgi Islemleri Ticaret A.S. | Apparatus and method for operating a distributed database with foreign tables |
| KR102453595B1 (ko) * | 2020-10-20 | 2022-10-14 | (주)퍼스트정보 | 관계형 데이터베이스 보존 방법 및 시스템 |
| JP2024075439A (ja) | 2022-11-22 | 2024-06-03 | 富士通株式会社 | クエリ実行方法およびクエリ実行プログラム |
-
1999
- 1999-07-16 JP JP20390899A patent/JP3492247B2/ja not_active Expired - Fee Related
Non-Patent Citations (2)
| Title |
|---|
| 志村壮是，吉川正俊，オブジェクト的関係を用いたＸＭＬ文書の汎用的な格納と検索，情報処理学会第５８回（平成１１年前期）全国大会講演論文集（３），１９９９年 ３月 ９日，第２６５〜２６６頁 |
| 田島敬史，半構造データのためのデータモデルと操作言語，情報処理学会論文誌，１９９９年 ２月１５日，第４０巻，第ＳＩＧ３（ＴＯＤ１）号，第１５２〜１７０頁 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001034619A (ja) | 2001-02-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3492247B2 (ja) | Ｘｍｌデータ検索システム | |
| US7072896B2 (en) | System and method for automatic loading of an XML document defined by a document-type definition into a relational database including the generation of a relational schema therefor | |
| US6721727B2 (en) | XML documents stored as column data | |
| Macleod | Storage and retrieval of structured documents | |
| US7031956B1 (en) | System and method for synchronizing and/or updating an existing relational database with supplemental XML data | |
| US7290012B2 (en) | Apparatus, system, and method for passing data between an extensible markup language document and a hierarchical database | |
| US6279005B1 (en) | Method and apparatus for generating paths in an open hierarchical data structure | |
| US7844633B2 (en) | System and method for storage, management and automatic indexing of structured documents | |
| US20020078041A1 (en) | System and method of translating a universal query language to SQL | |
| JP3492246B2 (ja) | Ｘｍｌデータ検索処理方法および検索処理システム | |
| CA2429095A1 (en) | System and method of data modelling | |
| US7287216B1 (en) | Dynamic XML processing system | |
| EP1192561A1 (en) | Database management system with capability of fine-grained indexing and querying | |
| JPH0550774B2 (ja) | ||
| US20050060307A1 (en) | System, method, and service for datatype caching, resolving, and escalating an SQL template with references | |
| JP5056384B2 (ja) | 検索プログラム、方法及び装置 | |
| JPH0212464A (ja) | データベース・システム | |
| JP4289022B2 (ja) | 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体 | |
| JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
| Škrbić et al. | Bibliographic records editor in XML native environment | |
| JP3842575B2 (ja) | 構造化文書検索方法、構造化文書管理装置及びプログラム | |
| Fousteris et al. | Updating multidimensional XML documents | |
| Tulchinsky et al. | Graph queries for data integration using XML | |
| Kim et al. | XQuery speedup by deploying structural redundancy in mapping XML into relations | |
| Roduner et al. | Accessing XML Data from an Object-Relational Mediator Database |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20031104 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081114 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081114 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091114 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101114 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |