JP3492247B2 - Xmlデータ検索システム - Google Patents
Xmlデータ検索システム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
【0001】
【発明の属する技術分野】本発明は、XMLで記述され
た大量のデータを関係データベースに格納し、検索する
XMLデータの検索システムに関し、特に、XML文書
の構造に依存せずにあらゆるXMLデータを格納できる
ようにし、また格納されたXMLデータに対するXML
の木構造を辿る問い合わせを高速に実行できるようにし
たXMLデータの検索システムに関するものである。
た大量のデータを関係データベースに格納し、検索する
XMLデータの検索システムに関し、特に、XML文書
の構造に依存せずにあらゆるXMLデータを格納できる
ようにし、また格納されたXMLデータに対するXML
の木構造を辿る問い合わせを高速に実行できるようにし
たXMLデータの検索システムに関するものである。
【0002】
【従来の技術】現在、XMLデータを格納するのに用い
られている手法は、大まかに次の2つのタイプに分類す
ることができる。 ファイル格納:XML文書をファイル形式のまま格納
する手法。この手法は、オリジナルのXMLファイルの
全体あるいは一部をそのまま利用することを目的として
おり、そのため、XML文書をファイル形式のまま格納
する。しかし、それだけでは、ファイルの数が増えたと
きに目的とするファイルを見つけ出すことが困難になる
ので、目的とするファイルを検索する為のインデックス
も用意しておく必要がある。
られている手法は、大まかに次の2つのタイプに分類す
ることができる。 ファイル格納:XML文書をファイル形式のまま格納
する手法。この手法は、オリジナルのXMLファイルの
全体あるいは一部をそのまま利用することを目的として
おり、そのため、XML文書をファイル形式のまま格納
する。しかし、それだけでは、ファイルの数が増えたと
きに目的とするファイルを見つけ出すことが困難になる
ので、目的とするファイルを検索する為のインデックス
も用意しておく必要がある。
【0003】テーブル格納:XMLを関係データベー
スのテーブルにマッピングして格納する手法。この手法
ではXML文書を構造化データと見なし、データベース
に格納することによって高速な検索を行なうことを目的
としている。そのため、この手法では、各エレメントを
関係データベースのテーブルの各カラムにマツピングし
て格納する。XMLデータをテーブルにマツピングする
為には、XMLの各エレメントをテーブルの各カラムに
どのようにマツピングするかというマツピング規則が必
要である。このマツピング規則はユーザが事前に指定す
る必要がある。
スのテーブルにマッピングして格納する手法。この手法
ではXML文書を構造化データと見なし、データベース
に格納することによって高速な検索を行なうことを目的
としている。そのため、この手法では、各エレメントを
関係データベースのテーブルの各カラムにマツピングし
て格納する。XMLデータをテーブルにマツピングする
為には、XMLの各エレメントをテーブルの各カラムに
どのようにマツピングするかというマツピング規則が必
要である。このマツピング規則はユーザが事前に指定す
る必要がある。
【0004】
【発明が解決しようとする課題】XMLデータを格納す
る際に一番問題となるのは、そのデータ構造が一意に定
まっていないという事である。特に、DTD(文書型宣
言) のないXMLデータでは、どこにどのようなタグが
出現するか分からず、データ構造は全く分からない。D
TDのあるXMLデータでさえも、DTDの中でタグの
繰り返しやタグの選択、タグの再帰的な宣言が許されて
いるので、データ構造が一意に定まらない。なお、この
ようなデータを半構造データと呼ぶ。このようなデータ
構造の定まっていないXMLデータを格納しようとする
と、格納スキーマの設計が問題となる。例えば、図8に
示される〔DTD〕を持つ、サンプルXMLデータ〔X
MLデータ〕をテーブル格納でデータベースに格納した
場合を考える。なお、このサンプルXMLデータは、2
冊の本の情報を含む書籍目録のデータである。
る際に一番問題となるのは、そのデータ構造が一意に定
まっていないという事である。特に、DTD(文書型宣
言) のないXMLデータでは、どこにどのようなタグが
出現するか分からず、データ構造は全く分からない。D
TDのあるXMLデータでさえも、DTDの中でタグの
繰り返しやタグの選択、タグの再帰的な宣言が許されて
いるので、データ構造が一意に定まらない。なお、この
ようなデータを半構造データと呼ぶ。このようなデータ
構造の定まっていないXMLデータを格納しようとする
と、格納スキーマの設計が問題となる。例えば、図8に
示される〔DTD〕を持つ、サンプルXMLデータ〔X
MLデータ〕をテーブル格納でデータベースに格納した
場合を考える。なお、このサンプルXMLデータは、2
冊の本の情報を含む書籍目録のデータである。
【0005】図9は上記XMLデータをテーブルに格納
した様子を示す図である。図9のテーブルでは、1タプ
ルが本1冊分の情報に相当していて、列にはXMLデー
タ中で出現する可能性のある全てのタグがとられてい
る。これを見ると、一見サンプルデータが問題なく格納
されているかのように見える。しかし、サンプルデータ
のDTDに書かれた定義には著者数の制限が無いのに、
図9のテーブルでは著者を格納するスペースは最大2人
分しか用意されていない。もしXMLデータの中に著者
がそれ以上存在したら、そのデータは格納できないか、
格納しても情報が一部欠損することになる。このよう
に、テーブル格納では、XMLのDTDで記述される繰
り返しタグを格納することができない。これは、テーブ
ル格納ではあらかじめ格納する要素を列として指定して
おく必要があるので、最大数が未定の繰り返し要素を表
現できないからである。また、同じ理由で再帰的に定義
されているタグも格納できない。さらに、そもそもXM
LデータにDTDが存在しなくて、どのようなタグが出
現するか分かっていないときには、テーブルの構造を決
められず、全く対応できない。
した様子を示す図である。図9のテーブルでは、1タプ
ルが本1冊分の情報に相当していて、列にはXMLデー
タ中で出現する可能性のある全てのタグがとられてい
る。これを見ると、一見サンプルデータが問題なく格納
されているかのように見える。しかし、サンプルデータ
のDTDに書かれた定義には著者数の制限が無いのに、
図9のテーブルでは著者を格納するスペースは最大2人
分しか用意されていない。もしXMLデータの中に著者
がそれ以上存在したら、そのデータは格納できないか、
格納しても情報が一部欠損することになる。このよう
に、テーブル格納では、XMLのDTDで記述される繰
り返しタグを格納することができない。これは、テーブ
ル格納ではあらかじめ格納する要素を列として指定して
おく必要があるので、最大数が未定の繰り返し要素を表
現できないからである。また、同じ理由で再帰的に定義
されているタグも格納できない。さらに、そもそもXM
LデータにDTDが存在しなくて、どのようなタグが出
現するか分かっていないときには、テーブルの構造を決
められず、全く対応できない。
【0006】一方、ファイル格納は、XMLデータをフ
ァイル形式のまま格納するので、DTDの無いXMLデ
ータであろうと半構造のXMLデータであろうと、格納
できないXMLデータは存在しない。しかし、それだけ
では大量に格納されたデータの中から自分の求める情報
だけを検索することができないので、検索用のインデッ
クスが必要となる。インデックスの構成は目的に応じて
色々と考えられ、簡単なものではタグ名と文字列の組を
キーにして、そのタグに囲まれてその文字列が出現して
いるようなXML文書を検索してくるというものがあ
る。しかし、そのような簡単なインデックスでは、タグ
の階層構造を考慮した検索は行なえない。タグの階層構
造の情報を持つようにインデックスを工夫することも考
えられるが、それでもなお次のことが問題として残る。
ァイル形式のまま格納するので、DTDの無いXMLデ
ータであろうと半構造のXMLデータであろうと、格納
できないXMLデータは存在しない。しかし、それだけ
では大量に格納されたデータの中から自分の求める情報
だけを検索することができないので、検索用のインデッ
クスが必要となる。インデックスの構成は目的に応じて
色々と考えられ、簡単なものではタグ名と文字列の組を
キーにして、そのタグに囲まれてその文字列が出現して
いるようなXML文書を検索してくるというものがあ
る。しかし、そのような簡単なインデックスでは、タグ
の階層構造を考慮した検索は行なえない。タグの階層構
造の情報を持つようにインデックスを工夫することも考
えられるが、それでもなお次のことが問題として残る。
【0007】(1)インデックスがXMLの木構造の全
ての情報を持っていないので、XMLデータの全情報を
使った検索ができない。 (2)インデックスが木構造を辿ることに最適化されて
いないので、そのような検索を行った場合は検索速度が
遅い。以上のように、データ構造が一意に定まっていな
いXMLデータにおいては、いかにしてDTD無しのX
MLデータや半構造のXMLデータを格納するか、ま
た、格納されたXMLデータに対していかにして木構造
を辿るような複雑な問い合わせを高速に実行できるよう
にするかといった問題がある。本発明は上記した事情に
鑑みなされたものであって、本発明の目的は、データ構
造が一意に定まっていないXMLデータをデータベース
に格納し、複雑な間合わせを高速に実行することができ
るXMLデータの検索システムを提供することである。
ての情報を持っていないので、XMLデータの全情報を
使った検索ができない。 (2)インデックスが木構造を辿ることに最適化されて
いないので、そのような検索を行った場合は検索速度が
遅い。以上のように、データ構造が一意に定まっていな
いXMLデータにおいては、いかにしてDTD無しのX
MLデータや半構造のXMLデータを格納するか、ま
た、格納されたXMLデータに対していかにして木構造
を辿るような複雑な問い合わせを高速に実行できるよう
にするかといった問題がある。本発明は上記した事情に
鑑みなされたものであって、本発明の目的は、データ構
造が一意に定まっていないXMLデータをデータベース
に格納し、複雑な間合わせを高速に実行することができ
るXMLデータの検索システムを提供することである。
【0008】
【課題を解決するための手段】図1は本発明の基本構成
を示す図である。同図に示すように、本発明のシステム
は、エレメントを中間ノードとし、エレメント値と属性
値を葉ノードとし、タグをリンクとする木構造で表現さ
れるXMLで記述されたデータを検索するシステムにお
いて、XMLデータを格納する格納手段1を設け、該格
納手段1の関係データベースに、少なくとも中間ノード
の情報を格納するための中間ノードテーブル2と、リン
クの情報を格納するためのリンクテーブル3と、葉ノー
ドの情報を格納するための葉ノードテーブル4とを設け
る。そして、上記XMLの木構造で表現されたXMLデ
ータをノード単位で分割し、上記テーブル2〜4に各ノ
ードとリンク情報を関係付けて格納する。XMLでは、
木構造を形成する中間ノードと、エレメントの値を持っ
ている葉ノードとでは、格納するために最適な格納構造
が異なるので、上記のようにそれぞれ最適化された別々
の専用テーブルに格納するのが望ましい。このように、
値を持つためのノードである葉ノードと木構造の情報を
持っためのノードである中間ノードを別々のテーブルに
格納することにより、値を格納するための格納スペース
を節約することが可能となる。各ノード間の接続情報を
保持する為のリンクも、リンクテーブル3に格納して持
っておく必要がある。また、属性情報を格納するための
属性テーブル5を別途設けてもよい。さらに、中間ノー
ドテーブル2に各ノードのルートからのフルパス情報を
IDで記述し、パス用のIDと文字列の対応表をパスI
Dテーブル6として別に持つことにより、格納スペース
の節約と、検索の高速化を図ることができる。同様に、
リンクテーブル3のタグ名と属性ノードテーブルの属性
名をIDで記述し、これらラベルのIDと文字列の対応
表をラベルIDテーブル7として別に持つことによっ
て、格納スペースの節約と文字列検索の高速化を図るこ
とができる。また、リンクテーブル3の中に各子エレメ
ントがそのエレメント内で出現した順序の情報を付加
し、葉ノードテーブルの中に各エレメント値がそのエレ
メント内で出現した順序の情報を付加することにより、
元のXML文書の復元が可能となる。
を示す図である。同図に示すように、本発明のシステム
は、エレメントを中間ノードとし、エレメント値と属性
値を葉ノードとし、タグをリンクとする木構造で表現さ
れるXMLで記述されたデータを検索するシステムにお
いて、XMLデータを格納する格納手段1を設け、該格
納手段1の関係データベースに、少なくとも中間ノード
の情報を格納するための中間ノードテーブル2と、リン
クの情報を格納するためのリンクテーブル3と、葉ノー
ドの情報を格納するための葉ノードテーブル4とを設け
る。そして、上記XMLの木構造で表現されたXMLデ
ータをノード単位で分割し、上記テーブル2〜4に各ノ
ードとリンク情報を関係付けて格納する。XMLでは、
木構造を形成する中間ノードと、エレメントの値を持っ
ている葉ノードとでは、格納するために最適な格納構造
が異なるので、上記のようにそれぞれ最適化された別々
の専用テーブルに格納するのが望ましい。このように、
値を持つためのノードである葉ノードと木構造の情報を
持っためのノードである中間ノードを別々のテーブルに
格納することにより、値を格納するための格納スペース
を節約することが可能となる。各ノード間の接続情報を
保持する為のリンクも、リンクテーブル3に格納して持
っておく必要がある。また、属性情報を格納するための
属性テーブル5を別途設けてもよい。さらに、中間ノー
ドテーブル2に各ノードのルートからのフルパス情報を
IDで記述し、パス用のIDと文字列の対応表をパスI
Dテーブル6として別に持つことにより、格納スペース
の節約と、検索の高速化を図ることができる。同様に、
リンクテーブル3のタグ名と属性ノードテーブルの属性
名をIDで記述し、これらラベルのIDと文字列の対応
表をラベルIDテーブル7として別に持つことによっ
て、格納スペースの節約と文字列検索の高速化を図るこ
とができる。また、リンクテーブル3の中に各子エレメ
ントがそのエレメント内で出現した順序の情報を付加
し、葉ノードテーブルの中に各エレメント値がそのエレ
メント内で出現した順序の情報を付加することにより、
元のXML文書の復元が可能となる。
【0009】本発明では、XMLの木構造をそのまま格
納手段1に格納するので、DTD無しのXMLデータや
半構造のXMLデータも格納できる。また、XMLの木
構造を全てデータベース上に格納しているので、木構造
の全ての情報を検索に利用することができる。しかしこ
れだけでは問い合わせが行なわれたときに、ノード単位
に分割して格納されているXMLデータの木構造を再結
合するのに時間がかかり、問い合わせの実行時間が遅く
なる。そこで本発明では、上記のテーブル2〜7に、X
MLデータへの問い合わせパターンを考慮してインデッ
クス8を張る。これにより、XMLの木構造を辿るよう
な複雑な問い合わせの実行を高速に行なうことを可能と
なる。上記XMLデータを検索するには、例えばXML
データ検索言語により、問い合わせを行う。これにより
問い合わせ処理手段9は、問い合わせ文の構文チェック
を行い問い合わせのための構文木を生成し、最適な実行
プランを生成する。この実行プランは、木構造検索用の
関数セットで記述される。この実行プランにより、上記
インデックス8を用いて木構造を辿る問い合わせを実行
し、要求された検索結果を出力する。
納手段1に格納するので、DTD無しのXMLデータや
半構造のXMLデータも格納できる。また、XMLの木
構造を全てデータベース上に格納しているので、木構造
の全ての情報を検索に利用することができる。しかしこ
れだけでは問い合わせが行なわれたときに、ノード単位
に分割して格納されているXMLデータの木構造を再結
合するのに時間がかかり、問い合わせの実行時間が遅く
なる。そこで本発明では、上記のテーブル2〜7に、X
MLデータへの問い合わせパターンを考慮してインデッ
クス8を張る。これにより、XMLの木構造を辿るよう
な複雑な問い合わせの実行を高速に行なうことを可能と
なる。上記XMLデータを検索するには、例えばXML
データ検索言語により、問い合わせを行う。これにより
問い合わせ処理手段9は、問い合わせ文の構文チェック
を行い問い合わせのための構文木を生成し、最適な実行
プランを生成する。この実行プランは、木構造検索用の
関数セットで記述される。この実行プランにより、上記
インデックス8を用いて木構造を辿る問い合わせを実行
し、要求された検索結果を出力する。
【0010】 本発明においては、次のように構成する
こともできる。 (1) テーブルに関係データベースの制約の機能を適用
することによって、XMLの構文規則をチェックする。 (2) リンクテーブルの中に、各エレメントの同ラベル
を持つ兄弟エレメント中での出現順序の情報を付加し、
各ラベルの出現順序を指定した問い合わせの実行を可能
とする。 (3) リンクテーブルにリンクの両節点の情報だけでな
くタグ名の情報も待つことによって、タグ名を指定して
リンクを辿る問い合わせを高速に実行する。 (4) 属性テーブルの中の属性ノードの接続先をリンク
ではなくて中間ノードにすることによって、属性を条件
にして木構造を辿る問い合わせを実行する際のテーブル
検索回数を削減し、問い合わせの高速実行を可能とす
る。 (5) 中間ノードテーブルのパスIDによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値をパスIDとノードIDの組とする
ことによってキー値の重複を無くす。 (6) 中間ノードテーブルの文書IDによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値を文書IDとノードIDの組とする
ことによってキー値の重複を無くす。
こともできる。 (1) テーブルに関係データベースの制約の機能を適用
することによって、XMLの構文規則をチェックする。 (2) リンクテーブルの中に、各エレメントの同ラベル
を持つ兄弟エレメント中での出現順序の情報を付加し、
各ラベルの出現順序を指定した問い合わせの実行を可能
とする。 (3) リンクテーブルにリンクの両節点の情報だけでな
くタグ名の情報も待つことによって、タグ名を指定して
リンクを辿る問い合わせを高速に実行する。 (4) 属性テーブルの中の属性ノードの接続先をリンク
ではなくて中間ノードにすることによって、属性を条件
にして木構造を辿る問い合わせを実行する際のテーブル
検索回数を削減し、問い合わせの高速実行を可能とす
る。 (5) 中間ノードテーブルのパスIDによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値をパスIDとノードIDの組とする
ことによってキー値の重複を無くす。 (6) 中間ノードテーブルの文書IDによる検索を高速
に行なうためのインデックスをB + -tree で構築する場
合において、キー値を文書IDとノードIDの組とする
ことによってキー値の重複を無くす。
【0011】
【発明の実施の形態】以下、本発明の実施の形態につい
て説明する。 (1) システム構成 図2は本発明の実施例のシステムの構成を示す図であ
る。同図に示すように、本実施例のシステムは大きくわ
けて、XMLデータ格納部11、XMLデータ格納部1
1にXMLデータを挿入するためのXMLデータ挿入モ
ジュール12、格納されたXMLデータへの問い合わせ
を処理する問い合わせ処理エンジン部13から構成され
る。XMLデータは、XMLデータ挿入モジュール12
によって、XMLデータ格納部11に挿入される。XM
Lデータ挿入モジュール12は、XMLパーザ12aと
ローダー12bから成り、XMLバーザ12aは入力さ
れたXMLデータを構文解析し、XMLデータの木構造
を、XMLデータ格納部11に格納できるようにノード
単位に分解する。また、ローダー12bは、そのノード
単位に分解された木構造をXMLデータ格納部11のテ
ーブルに挿入する。
て説明する。 (1) システム構成 図2は本発明の実施例のシステムの構成を示す図であ
る。同図に示すように、本実施例のシステムは大きくわ
けて、XMLデータ格納部11、XMLデータ格納部1
1にXMLデータを挿入するためのXMLデータ挿入モ
ジュール12、格納されたXMLデータへの問い合わせ
を処理する問い合わせ処理エンジン部13から構成され
る。XMLデータは、XMLデータ挿入モジュール12
によって、XMLデータ格納部11に挿入される。XM
Lデータ挿入モジュール12は、XMLパーザ12aと
ローダー12bから成り、XMLバーザ12aは入力さ
れたXMLデータを構文解析し、XMLデータの木構造
を、XMLデータ格納部11に格納できるようにノード
単位に分解する。また、ローダー12bは、そのノード
単位に分解された木構造をXMLデータ格納部11のテ
ーブルに挿入する。
【0012】図3に上記XMLデータの格納処理を示す
フローチャートを示す。本実施例においてXMLデータ
の格納処理は次のように行われる。まず、ステップS1
において、XMLファイルを読み込む。ステップS2に
おいて、XMLパーザにより、入力ファイルの構文解析
を行う。解析が成功した場合には、ステップS3に行
き、XMLパーザが解析結果として、XMLの木構造の
ノード情報とリンク情報を中間形式としてファイル出力
する。また、解析が成功しない場合には、構文解析失敗
としてエラー出力し処理を終了する。ステップS4にお
いて、生成された中間形式ファイルを読み込み、ステッ
プS5において、読み込んだXMLデータをローダによ
って関係データベースの各テーブルに挿入し、処理を終
了する。また、上記挿入が成功しない場合には、データ
挿入失敗としてエラー出力をして処理を終了する。
フローチャートを示す。本実施例においてXMLデータ
の格納処理は次のように行われる。まず、ステップS1
において、XMLファイルを読み込む。ステップS2に
おいて、XMLパーザにより、入力ファイルの構文解析
を行う。解析が成功した場合には、ステップS3に行
き、XMLパーザが解析結果として、XMLの木構造の
ノード情報とリンク情報を中間形式としてファイル出力
する。また、解析が成功しない場合には、構文解析失敗
としてエラー出力し処理を終了する。ステップS4にお
いて、生成された中間形式ファイルを読み込み、ステッ
プS5において、読み込んだXMLデータをローダによ
って関係データベースの各テーブルに挿入し、処理を終
了する。また、上記挿入が成功しない場合には、データ
挿入失敗としてエラー出力をして処理を終了する。
【0013】格納されたXMLデータに対する問い合わ
せは、XMLデータ問い合わせ言語で行なわれ、その問
い合わせは問い合わせ処理エンジン13で処理される。
問い合わせ処理エンジン13は、問い合わせ言語のパー
ザ13a、問い合わせ最適化エンジン13b、木構造検
索用API(アプリケーション・プログラミング・イン
タフェース) 13cから成る。問い合わせ言語のパーザ
13aは、入力された問い合わせ文の構文チェックを行
い問い合わせのための構文木を生成する。問い合わせ最
適化エンジン13bは、上記構文木を基に、最適な実行
プランを生成する。この実行プランは、木構造検索用A
PI13cの関数セットで記述される。木構造検索用A
PI13cは、XMLデータ格納部11とのインタフェ
ースで、XMLの木構造上での基本的な検索を行なう関
数のセットである。
せは、XMLデータ問い合わせ言語で行なわれ、その問
い合わせは問い合わせ処理エンジン13で処理される。
問い合わせ処理エンジン13は、問い合わせ言語のパー
ザ13a、問い合わせ最適化エンジン13b、木構造検
索用API(アプリケーション・プログラミング・イン
タフェース) 13cから成る。問い合わせ言語のパーザ
13aは、入力された問い合わせ文の構文チェックを行
い問い合わせのための構文木を生成する。問い合わせ最
適化エンジン13bは、上記構文木を基に、最適な実行
プランを生成する。この実行プランは、木構造検索用A
PI13cの関数セットで記述される。木構造検索用A
PI13cは、XMLデータ格納部11とのインタフェ
ースで、XMLの木構造上での基本的な検索を行なう関
数のセットである。
【0014】次に、上記システムにおける各部の構成に
ついてさらに詳細に説明する。 (1) テーブル構成 まず、上記XMLデータ格納部11に格納されるテーブ
ルの構成について説明する。XMLデータを木構造で表
現する方法はいくつかあるが、本実施例では図4に示す
木構造表現を想定している。図4は、前記図8に示した
XMLデータを木構造で表現したものである。この木構
造表現において、丸い中間ノードはエレメントを表して
おり、ノードの親子関係がエレメントの包含関係を表し
ている。
ついてさらに詳細に説明する。 (1) テーブル構成 まず、上記XMLデータ格納部11に格納されるテーブ
ルの構成について説明する。XMLデータを木構造で表
現する方法はいくつかあるが、本実施例では図4に示す
木構造表現を想定している。図4は、前記図8に示した
XMLデータを木構造で表現したものである。この木構
造表現において、丸い中間ノードはエレメントを表して
おり、ノードの親子関係がエレメントの包含関係を表し
ている。
【0015】また、ノードの丸の中の数字はノードID
を表している。ノードとノードを結ぶリンク(枝) はタ
グを表しており、リンクの横に書かれている文字列はタ
グ名を表している。三角の葉ノードはエレメントの値を
表し、四角い葉ノードはタグに付けられた属性(Atrrib
ute)を表している。値を持つのはこの2つの葉ノードだ
けである。ノードを分割してデータベースに格納すると
きに、ノードの情報だけをデータベースのテーブルに格
納したのでは、木構造のノード間の繋がり、つまりリン
クの情報が欠落してしまう。そこで、リンクの情報はリ
ンクの情報としてそれを格納する専用のテーブルを用意
する。またノードも、中間ノードと、エレメント値の葉
ノード、属性の葉ノードとは最適な格納構造が異なるの
で、別々のテーブルに格納する必要がある。
を表している。ノードとノードを結ぶリンク(枝) はタ
グを表しており、リンクの横に書かれている文字列はタ
グ名を表している。三角の葉ノードはエレメントの値を
表し、四角い葉ノードはタグに付けられた属性(Atrrib
ute)を表している。値を持つのはこの2つの葉ノードだ
けである。ノードを分割してデータベースに格納すると
きに、ノードの情報だけをデータベースのテーブルに格
納したのでは、木構造のノード間の繋がり、つまりリン
クの情報が欠落してしまう。そこで、リンクの情報はリ
ンクの情報としてそれを格納する専用のテーブルを用意
する。またノードも、中間ノードと、エレメント値の葉
ノード、属性の葉ノードとは最適な格納構造が異なるの
で、別々のテーブルに格納する必要がある。
【0016】本実施例で使用するテーブルは、全部で次
の6つである。 中間ノードテーブル これは中間ノードの情報を格納するテーブルである。ノ
ードID(id)の他に、そのノードが含まれている文書の
文書ID(docid) 、そのノードまでのルートからのフル
パスのID(pathid)をカラムとして持っている。 リンクテーブル これはノード間のリンクを格納するテーブルである。ノ
ードID(id)、リンクのラベル(タグ名) のID(labe
lid)、子ノードのノードID(child) 、その子ノードの
全兄弟ノード中での出現順序(tord:total order)、その
子ノードの同ラベルを持つ兄弟ノード中での出現順序(p
ord:partial order)をカラムとして持っている。上記の
ように、リンクテーブル中にラベル(タグ名) のID(l
abelid)を付加することによりタグ名を指定してリンク
を辿る問い合わせを高速に実行することが可能となる。
の6つである。 中間ノードテーブル これは中間ノードの情報を格納するテーブルである。ノ
ードID(id)の他に、そのノードが含まれている文書の
文書ID(docid) 、そのノードまでのルートからのフル
パスのID(pathid)をカラムとして持っている。 リンクテーブル これはノード間のリンクを格納するテーブルである。ノ
ードID(id)、リンクのラベル(タグ名) のID(labe
lid)、子ノードのノードID(child) 、その子ノードの
全兄弟ノード中での出現順序(tord:total order)、その
子ノードの同ラベルを持つ兄弟ノード中での出現順序(p
ord:partial order)をカラムとして持っている。上記の
ように、リンクテーブル中にラベル(タグ名) のID(l
abelid)を付加することによりタグ名を指定してリンク
を辿る問い合わせを高速に実行することが可能となる。
【0017】葉ノードテーブル
これはエレメント値の葉ノードを格納するテーブルであ
る。そのエレメントにあたる中間ノードのノードID(i
d)の他に、エレメントの値(value) と、そのエレメント
中でその値が出現した順序(order) をカラムとして持っ
ている。このように、値を持つための葉ノードテーブル
を、前記中間ノードテーブルとは別に設けることによ
り、値を格納するスペースを節約することができる。
る。そのエレメントにあたる中間ノードのノードID(i
d)の他に、エレメントの値(value) と、そのエレメント
中でその値が出現した順序(order) をカラムとして持っ
ている。このように、値を持つための葉ノードテーブル
を、前記中間ノードテーブルとは別に設けることによ
り、値を格納するスペースを節約することができる。
【0018】属性ノードテーブル
これはタグにつけられた属性(例えば図8における<boo
k year="1995">におけるyear)を格納するテーブルであ
る。そのタグが含まれるエレメントにあたる中間ノード
のノードID(id)の他に、属性名のID(labelid) 、属
性値(Attvalue)をカラムとして待つ。なお、属性テーブ
ルに関係データベースの制約機能を用いて、(id,labeli
d)の組がユニークという制約をかけておくことによっ
て、「同一のタグ内では同一の属性名は出現してはなら
ない」というXMLの属性に関する構文規則をチェック
することができる。また、本実施例で想定している木構
造表現では、XMLのタグが木構造のリンクに相当する
ので、XMLのタグに付けられる属性は本来ならばリン
クに付くべきである。しかし、図4では、属性はリンク
に対してではなく、その下のノードに付いている。これ
は、検索時のテーブル参照の回数を少なくするためであ
る。すなわち、属性を条件として木構造を辿る問い合わ
せを実行する際のテーブル検索回数を削減し、問い合わ
せの高速化を図ることが可能となる。
k year="1995">におけるyear)を格納するテーブルであ
る。そのタグが含まれるエレメントにあたる中間ノード
のノードID(id)の他に、属性名のID(labelid) 、属
性値(Attvalue)をカラムとして待つ。なお、属性テーブ
ルに関係データベースの制約機能を用いて、(id,labeli
d)の組がユニークという制約をかけておくことによっ
て、「同一のタグ内では同一の属性名は出現してはなら
ない」というXMLの属性に関する構文規則をチェック
することができる。また、本実施例で想定している木構
造表現では、XMLのタグが木構造のリンクに相当する
ので、XMLのタグに付けられる属性は本来ならばリン
クに付くべきである。しかし、図4では、属性はリンク
に対してではなく、その下のノードに付いている。これ
は、検索時のテーブル参照の回数を少なくするためであ
る。すなわち、属性を条件として木構造を辿る問い合わ
せを実行する際のテーブル検索回数を削減し、問い合わ
せの高速化を図ることが可能となる。
【0019】パスIDテーブル
これはパスIDとパスの文字列の対応表である。パスの
文字列を中間ノードテーブルに直接書き込まないでこの
ように別に持っているのは、スペースの節約の為もある
が、パス名の文字列マッチングを含む検索が行なわれた
ときに、検索対象が少なくてすみ、検索が高速化できる
からでもある。 ラベルIDテーブル これはラベルIDとラベルの文字列の対応表である。こ
のように、リンクテーブルのタグ名と、属性ノードテー
ブルの属性名をIDで記述し、このラベルのIDと文字
列の対応表をラベルIDテーブルとして別に持つことに
より、パスIDテーブルと同様、格納スペースの節約
と、検索の高速化を図ることができる。
文字列を中間ノードテーブルに直接書き込まないでこの
ように別に持っているのは、スペースの節約の為もある
が、パス名の文字列マッチングを含む検索が行なわれた
ときに、検索対象が少なくてすみ、検索が高速化できる
からでもある。 ラベルIDテーブル これはラベルIDとラベルの文字列の対応表である。こ
のように、リンクテーブルのタグ名と、属性ノードテー
ブルの属性名をIDで記述し、このラベルのIDと文字
列の対応表をラベルIDテーブルとして別に持つことに
より、パスIDテーブルと同様、格納スペースの節約
と、検索の高速化を図ることができる。
【0020】また、上記のように、リンクテーブル中
に、子ノードの全兄弟ノード中での出現順序(tord:tota
l order)の情報を付加し、また、葉ノードテーブル中
に、各エレメント値がそのエレメント内で出現した順序
(order) の情報を付加することに、XMLデータ格納部
11に格納されるノード単位に分解されたXMLデータ
から、元のXML文書を復元することが可能となる。例
えば、「今日は <天気> 晴れ</天気> だった。○○は <
場所> デパート</場所> へでかけた。」のようにタグで
区切られた文章を復元することも可能になる。また、リ
ンクテーブル中に、各エレメントの同ラベルを持つ兄弟
ノード中での出現順序(pord:partial order)の情報を付
加することにより、各ラベルの出現順序を指定した問い
合わせを高速に実行することが可能となる。
に、子ノードの全兄弟ノード中での出現順序(tord:tota
l order)の情報を付加し、また、葉ノードテーブル中
に、各エレメント値がそのエレメント内で出現した順序
(order) の情報を付加することに、XMLデータ格納部
11に格納されるノード単位に分解されたXMLデータ
から、元のXML文書を復元することが可能となる。例
えば、「今日は <天気> 晴れ</天気> だった。○○は <
場所> デパート</場所> へでかけた。」のようにタグで
区切られた文章を復元することも可能になる。また、リ
ンクテーブル中に、各エレメントの同ラベルを持つ兄弟
ノード中での出現順序(pord:partial order)の情報を付
加することにより、各ラベルの出現順序を指定した問い
合わせを高速に実行することが可能となる。
【0021】一例として、図8のサンプルXMLデータ
(図4の木構造表現) を上記のテーブル群で格納した様
子を図5、図6に示す。図5は中間ノードテーブル、リ
ンクテーブルの例を示す図である。中間ノードテーブル
において、例えば、第1行目のid(=5) は図4におい
て" 5" と記されたノードを示し、そのノードが含まれ
ている文書の文書ID(docid) は1である。また、その
ノードまでのルートからのフルパスのID(pathid)は1
であり、このIDに対応したpathは、"bib.book.publi
sher.name"である。また、リンクテーブルにおいて、例
えば1行目のid(=4)は図4において、" 4" と記さ
れたノードを示し、そのlabelidは5であり、このlabe
lid に対応するlabel は"name"である。また、その出現
順序を示すtord,pord はそれぞれ" 0"," 0" であり、
子ノードは、図4で "5" と記されたノードである。
(図4の木構造表現) を上記のテーブル群で格納した様
子を図5、図6に示す。図5は中間ノードテーブル、リ
ンクテーブルの例を示す図である。中間ノードテーブル
において、例えば、第1行目のid(=5) は図4におい
て" 5" と記されたノードを示し、そのノードが含まれ
ている文書の文書ID(docid) は1である。また、その
ノードまでのルートからのフルパスのID(pathid)は1
であり、このIDに対応したpathは、"bib.book.publi
sher.name"である。また、リンクテーブルにおいて、例
えば1行目のid(=4)は図4において、" 4" と記さ
れたノードを示し、そのlabelidは5であり、このlabe
lid に対応するlabel は"name"である。また、その出現
順序を示すtord,pord はそれぞれ" 0"," 0" であり、
子ノードは、図4で "5" と記されたノードである。
【0022】図6は葉ノードテーブル、属性ノードテー
ブル、パスIDテーブル、ラベルIDテーブルの例を示
す図である。葉ノードテーブルにおいて、例えば第1行
目のid(=5) は図4において、"5" と記されたノー
ドを示し、そのorder は" 0" 、またその葉ノードの値
(value)は"Addison-Wesley"である。属性ノードテーブ
ルにおいて、例えば第1行目のid(=3) は図4におい
て、”3" と記されたノードを示し、そのlabelid は3
("year"に対応) 、その属性値(attvalue ) は "19
95”である。また、パスIDテーブル、ラベルIDテ
ーブルにはそれぞれ、上記各テーブル中のpathid、labe
lid に対応したパスの文字列、ラベルの文字列が格納さ
れ、例えば、pathid=”1" に対応した文字列は前記し
たように" bib.book.publisher.name"であり、また、
例えばlabelid =”1" に対応した文字列は" bib"であ
る。
ブル、パスIDテーブル、ラベルIDテーブルの例を示
す図である。葉ノードテーブルにおいて、例えば第1行
目のid(=5) は図4において、"5" と記されたノー
ドを示し、そのorder は" 0" 、またその葉ノードの値
(value)は"Addison-Wesley"である。属性ノードテーブ
ルにおいて、例えば第1行目のid(=3) は図4におい
て、”3" と記されたノードを示し、そのlabelid は3
("year"に対応) 、その属性値(attvalue ) は "19
95”である。また、パスIDテーブル、ラベルIDテ
ーブルにはそれぞれ、上記各テーブル中のpathid、labe
lid に対応したパスの文字列、ラベルの文字列が格納さ
れ、例えば、pathid=”1" に対応した文字列は前記し
たように" bib.book.publisher.name"であり、また、
例えばlabelid =”1" に対応した文字列は" bib"であ
る。
【0023】(2) インデックスの構成
本実施例においては、本来連結されていたはずの木構造
のノードが、前記したように1つ1つに分割されて関係
データベースのテーブルに格納されている。このため
に、木構造を辿る問い合わせが行なわれた場合、問い合
わせで辿る部分のリンクを連結し直すためにジョイン操
作が行なわれる。このジョイン操作の速度は全体の検索
速度に大きく影響するので、ジョイン操作を高速に行な
えるようにインデックスを効果的に張っておく必要があ
る。また、問い合わせが行なわれる場合、検索条件とし
て指定されるのは、エレメントの値、属性、パス、出現
順序などである。それらの検索も高速に行なう必要があ
るので、そこにもインデックスを用意しておく必要があ
る。
のノードが、前記したように1つ1つに分割されて関係
データベースのテーブルに格納されている。このため
に、木構造を辿る問い合わせが行なわれた場合、問い合
わせで辿る部分のリンクを連結し直すためにジョイン操
作が行なわれる。このジョイン操作の速度は全体の検索
速度に大きく影響するので、ジョイン操作を高速に行な
えるようにインデックスを効果的に張っておく必要があ
る。また、問い合わせが行なわれる場合、検索条件とし
て指定されるのは、エレメントの値、属性、パス、出現
順序などである。それらの検索も高速に行なう必要があ
るので、そこにもインデックスを用意しておく必要があ
る。
【0024】図7に、上記図5、図6に示したテーブル
に張ったインデックスの一覧を示す。このインデックス
は B+ -tree で張ってあり、キーが複数の属性の組から
なるインデックスは、その組の先頭からの部分的な属性
の組で検索に用いることもできる。なお中間ノードテー
ブルに張ってあるインデックスでキーが(pathid,id) の
ものは、あるパスに該当する全てのノードを検索してく
るときに使用するものである。このインデックスのキー
は、一見pathid単独で構わないように思われるかもしれ
ない。しかしキーをpathidだけにすると、同じキー値を
持つエントリが多量に発生して、B + -tree インデック
スが機能しなくなる。上記のようにキー値をパスID(p
athid)とノードのID(id)の組とすることにより、キー
値の重複を無くすことができ、B + -tree の検索を高速
に行うことができる。また、中間ノードテーブルに張っ
てあるインデックスでキーが(docid,id)も同様であり、
文書ID(docid) とノードのID(id)の組とすることに
より、キー値の重複を無くすことができ、B + -tree の
検索を高速に行うことができる。
に張ったインデックスの一覧を示す。このインデックス
は B+ -tree で張ってあり、キーが複数の属性の組から
なるインデックスは、その組の先頭からの部分的な属性
の組で検索に用いることもできる。なお中間ノードテー
ブルに張ってあるインデックスでキーが(pathid,id) の
ものは、あるパスに該当する全てのノードを検索してく
るときに使用するものである。このインデックスのキー
は、一見pathid単独で構わないように思われるかもしれ
ない。しかしキーをpathidだけにすると、同じキー値を
持つエントリが多量に発生して、B + -tree インデック
スが機能しなくなる。上記のようにキー値をパスID(p
athid)とノードのID(id)の組とすることにより、キー
値の重複を無くすことができ、B + -tree の検索を高速
に行うことができる。また、中間ノードテーブルに張っ
てあるインデックスでキーが(docid,id)も同様であり、
文書ID(docid) とノードのID(id)の組とすることに
より、キー値の重複を無くすことができ、B + -tree の
検索を高速に行うことができる。
【0025】(3) 問い合わせの実行
前記したように、格納されたXMLデータに対する問い
合わせは、例えばXMLデータの問い合わせ言語で行な
われる。XMLデータのための検索言語の一つとして検
索言語XQLがある。XQLによる問い合わせ文を、例
により簡単に説明する。
合わせは、例えばXMLデータの問い合わせ言語で行な
われる。XMLデータのための検索言語の一つとして検
索言語XQLがある。XQLによる問い合わせ文を、例
により簡単に説明する。
【0026】
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
を検索結果として得たい」という意味である。
【0027】上記に示すように、問い合わせ文は大き
く、SELECT、FROM、WHERE の3つの部分に別れている。
SELECTの部分では検索結果として得たいエレメントのプ
ロジェクションを指定する。FROMの部分では検索の対象
となるエレメントを指定している。WHERE の部分では検
索の条件のセレクションを指定する。上記のような問い
合わせは前記したように、問い合わせ処理エンジン13
で処理される。問い合わせ処理エンジン13では、上記
のような問い合わせ文の構文チェックを行い問い合わせ
のための構文木を生成する。そして、該構文木を基に、
最適な実行プランを生成する。この実行プランは、木構
造検索用の関数セットで記述される。
く、SELECT、FROM、WHERE の3つの部分に別れている。
SELECTの部分では検索結果として得たいエレメントのプ
ロジェクションを指定する。FROMの部分では検索の対象
となるエレメントを指定している。WHERE の部分では検
索の条件のセレクションを指定する。上記のような問い
合わせは前記したように、問い合わせ処理エンジン13
で処理される。問い合わせ処理エンジン13では、上記
のような問い合わせ文の構文チェックを行い問い合わせ
のための構文木を生成する。そして、該構文木を基に、
最適な実行プランを生成する。この実行プランは、木構
造検索用の関数セットで記述される。
【0028】次に、上記XMLデータに対する問い合わ
せ処理が、どのように行なわれるかを説明する。ここで
は、図8のサンプルXMLデータを、XMLデータ格納
部11に格納し、前述した図5、図6に示したテーブル
に挿入した場合を例として、上記のように「著者がDarw
enである本のタイトルを求めよ」という問い合わせを行
なった場合について説明する。この場合のテーブル検索
は、次のように行われる。なお、下記1. 〜10. の処
理は、上記木構造検索用の関数により実行される。
せ処理が、どのように行なわれるかを説明する。ここで
は、図8のサンプルXMLデータを、XMLデータ格納
部11に格納し、前述した図5、図6に示したテーブル
に挿入した場合を例として、上記のように「著者がDarw
enである本のタイトルを求めよ」という問い合わせを行
なった場合について説明する。この場合のテーブル検索
は、次のように行われる。なお、下記1. 〜10. の処
理は、上記木構造検索用の関数により実行される。
【0029】1. 葉ノードテーブルを検索して、値が
“Darwen" であるノードのノードID(=16) を得
る。 2. パスIDテーブルを検索して、パス"bib.book.auth
or.lastname " のパスID(=4) を得る。 3. 中間ノードテーブルを上記1. で得られたノードI
D(=16) で検索して、得られたパスID(=4) が
上記2. で得られたパスID(=4) と一致することを
確認する。 4. ラベルIDテーブルを検索して、ラベル"lastname"
のラベルID(=8) を得る。 5. リンクテーブルを検索して、上記1. で得られたノ
ードID(=16) と上記4. で得られたラベルID
(=8) から、親ノードのノードID(=15) を得
る。 6. ラベルIDテーブルを検索して、ラベル" author "
のラベルID(=7) を得る。 7. リンクテーブルを検索して、上記5. で得られたノ
ードID(=15) と上記6. で得られたラベルID
(=7) から、親ノードのノードID(=9)を得る。 8. ラベルIDテーブルを検索して、ラベル"title" の
ラベルID(=6) を得る。 9. リンクテーブルを検索して上記7. で得られたノー
ドID(=9) と上記8. で得られたラベルID(=
6) から、子ノードのノードID(=12) を得る。 10. 葉ノードテーブルを検索して、上記9. で得られ
たノードID(=12)から、そのノードの値("Foundat
ion for Object/Relational Database") を得る。以上
のようにして得られた検索結果は、問い合わせ処理エン
ジン13を介して出力され、ユーザに提示される。
“Darwen" であるノードのノードID(=16) を得
る。 2. パスIDテーブルを検索して、パス"bib.book.auth
or.lastname " のパスID(=4) を得る。 3. 中間ノードテーブルを上記1. で得られたノードI
D(=16) で検索して、得られたパスID(=4) が
上記2. で得られたパスID(=4) と一致することを
確認する。 4. ラベルIDテーブルを検索して、ラベル"lastname"
のラベルID(=8) を得る。 5. リンクテーブルを検索して、上記1. で得られたノ
ードID(=16) と上記4. で得られたラベルID
(=8) から、親ノードのノードID(=15) を得
る。 6. ラベルIDテーブルを検索して、ラベル" author "
のラベルID(=7) を得る。 7. リンクテーブルを検索して、上記5. で得られたノ
ードID(=15) と上記6. で得られたラベルID
(=7) から、親ノードのノードID(=9)を得る。 8. ラベルIDテーブルを検索して、ラベル"title" の
ラベルID(=6) を得る。 9. リンクテーブルを検索して上記7. で得られたノー
ドID(=9) と上記8. で得られたラベルID(=
6) から、子ノードのノードID(=12) を得る。 10. 葉ノードテーブルを検索して、上記9. で得られ
たノードID(=12)から、そのノードの値("Foundat
ion for Object/Relational Database") を得る。以上
のようにして得られた検索結果は、問い合わせ処理エン
ジン13を介して出力され、ユーザに提示される。
【0030】
【発明の効果】以上説明したように、本発明において
は、関係データベースに、中間ノードの情報を格納する
ための中間ノードテーブルと、リンクの情報を格納する
ためのリンクテーブルと、葉ノードの情報を格納するた
めの葉ノードテーブル等のテーブルを設け、XMLの木
構造をノードとリンクに分解して、上記テーブルに各ノ
ードとリンク情報を関係付けて格納し、上記テーブルを
参照して木構造を辿る問い合わせを実行し、XMLデー
タを検索するようにしたので、データ構造が一意に定ま
っていないXMLデータに対する複雑な問い合わせを高
速に実行することができる。また、XMLの木構造をそ
のまま格納手段に格納するので、DTD無しのXMLデ
ータや半構造のXMLデータも格納することができる。
さらにXMLの木構造を全てデータベース上に格納して
いるので、木構造の全ての情報を検索に利用することが
できる。
は、関係データベースに、中間ノードの情報を格納する
ための中間ノードテーブルと、リンクの情報を格納する
ためのリンクテーブルと、葉ノードの情報を格納するた
めの葉ノードテーブル等のテーブルを設け、XMLの木
構造をノードとリンクに分解して、上記テーブルに各ノ
ードとリンク情報を関係付けて格納し、上記テーブルを
参照して木構造を辿る問い合わせを実行し、XMLデー
タを検索するようにしたので、データ構造が一意に定ま
っていないXMLデータに対する複雑な問い合わせを高
速に実行することができる。また、XMLの木構造をそ
のまま格納手段に格納するので、DTD無しのXMLデ
ータや半構造のXMLデータも格納することができる。
さらにXMLの木構造を全てデータベース上に格納して
いるので、木構造の全ての情報を検索に利用することが
できる。
【図1】本発明の基本構成図である。
【図2】本発明の実施例のシステムの構成例を示す図で
ある。
ある。
【図3】本発明の実施例のシステムにおける格納処理フ
ローを示す図である。
ローを示す図である。
【図4】XMLデータの木構造表現の一例を示す図であ
る。
る。
【図5】本発明の実施例のテーブル構成の一例を示す図
(1) である。
(1) である。
【図6】本発明の実施例のテーブル構成の一例を示す図
(2) である。
(2) である。
【図7】本発明の実施例のイッデックス一覧を示す図で
ある。
ある。
【図8】XMLデータの一例を示す図である。
【図9】図8のXMLデータをテーブルに格納した様子
を示す図である。
を示す図である。
1 XMLデータ格納格納手段
2 中間ノードテーブル
3 リンクテーブル
4 葉ノードテーブル
5 属性テーブル
6 パスIDテーブル
7 ラベルIDテーブル
8 インデックス
9 問い合わせ処理手段
11 XMLデータ格納部
12 XMLデータ挿入モジュール
12a XMLパーザ
12b ローダ
13 問い合わせ処理エンジン部
13a 問い合わせ言語のパーザ
13b 問い合わせ最適化エンジン
13c 木構造検索用
フロントページの続き
(56)参考文献 志村壮是,吉川正俊,オブジェクト的
関係を用いたXML文書の汎用的な格納
と検索,情報処理学会第58回(平成11年
前期)全国大会講演論文集(3),1999
年 3月 9日,第265〜266頁
田島敬史,半構造データのためのデー
タモデルと操作言語,情報処理学会論文
誌,1999年 2月15日,第40巻,第SI
G3(TOD1)号,第152〜170頁
(58)調査した分野(Int.Cl.7,DB名)
G06F 17/30
G06F 12/00
JICSTファイル(JOIS)
Claims (3)
- 【請求項1】 エレメントを中間ノードとし、エレメン
ト値と属性値を葉ノードとし、タグをリンクとする木構
造で表現されるXMLで記述されたデータを検索するシ
ステムであって、 上記システムは、XMLデータを格納する格納手段を備
え、該格納手段の関係データベースに、少なくとも中間
ノードの情報を格納するための中間ノードテーブルと、
リンクの情報を格納するためのリンクテーブルと、葉ノ
ードの情報を格納するための葉ノードテーブルとを設
け、中間ノードテーブルに、ノードIDによる検索を高速に
行なうためのインデックスと、テーブルの文書IDによ
る検索を高速に行なうためのインデックスと、パスによ
る検索を高速に行なうためのインデックスを用意し、 リンクテーブルに、親ノードから子ノードを高速に検索
するためのインデックスと、子ノードから親ノードを高
速に検索するためのインデックスを用意し、 葉ノードテーブルに、ノードIDからそのノードの値を
得るためのインデックスと、ある値を持つノードを検索
するためのインデックスを用意し、 上記XMLの木構造をノードとリンクに分解して、上記
テーブルに各ノードとリンク情報を関係付けて格納し、
上記テーブルを参照して、上記インデックスを用いて木
構造を辿る問い合わせを実行し、XMLデータを検索す
ることを特徴とするXMLデータ検索システム。 - 【請求項2】 関係データベースに、パスの文字列とパ
ス用のIDの対応表であるパスIDテーブルと、ラベル
の文字列とラベル用IDの対応表であるラベルIDテー
ブルとを設け、パスIDテーブルに、パスの文字列に対応するバスID
を検索するためのインデックスを用意し、ラベルIDテ
ーブルに、ラベルの文字列に対応するラベルIDを検索
するためのインデックスを用意し、 上記インデックスを用いて木構造を辿る問い合わせを実
行することを特徴とする請求項1のXMLデータ検索シ
ステム。 - 【請求項3】 リンクテーブルの中に各子エレメントが
そのエレメント内で出現した順序の情報を付加し、葉ノ
ードテーブルの中に各エレメント値がそのエレメント内
で出現した順序の情報を付加し、上記情報により元のX
ML文書の復元を可能としたことを特徴とする請求項1
または請求項2のXMLデータ検索システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20390899A JP3492247B2 (ja) | 1999-07-16 | 1999-07-16 | Xmlデータ検索システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP20390899A JP3492247B2 (ja) | 1999-07-16 | 1999-07-16 | Xmlデータ検索システム |
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 | Xmlデータ検索システム |
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 | 삼성전자주식회사 | 관계형 데이터베이스에서 정규 경로식 질의를 처리하는xml 인덱싱 방법과 자료구조 |
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 | オラクル・インターナショナル・コーポレイション | Xmlデータにアクセスするためのインデックス |
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 | 삼성전자주식회사 | 관계형 dbms를 이용한 xml 데이터 관리 방법 |
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 | 고려대학교 산학협력단 | 단순 경로 질의에 대응하는 압축된 xml 스트림 생성방법, 단순 경로 질의에 대응하는 xml 스트림의 선택적수신 방법 및 그 장치 |
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 |
---|
志村壮是,吉川正俊,オブジェクト的関係を用いたXML文書の汎用的な格納と検索,情報処理学会第58回(平成11年前期)全国大会講演論文集(3),1999年 3月 9日,第265〜266頁 |
田島敬史,半構造データのためのデータモデルと操作言語,情報処理学会論文誌,1999年 2月15日,第40巻,第SIG3(TOD1)号,第152〜170頁 |
Also Published As
Publication number | Publication date |
---|---|
JP2001034619A (ja) | 2001-02-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3492247B2 (ja) | Xmlデータ検索システム | |
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) | Xmlデータ検索処理方法および検索処理システム | |
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 |