[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP2006127229A - 構造化文書検索システム、構造化文書検索方法及びプログラム - Google Patents

構造化文書検索システム、構造化文書検索方法及びプログラム Download PDF

Info

Publication number
JP2006127229A
JP2006127229A JP2004316084A JP2004316084A JP2006127229A JP 2006127229 A JP2006127229 A JP 2006127229A JP 2004316084 A JP2004316084 A JP 2004316084A JP 2004316084 A JP2004316084 A JP 2004316084A JP 2006127229 A JP2006127229 A JP 2006127229A
Authority
JP
Japan
Prior art keywords
node
search
request
traverse
structured document
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.)
Pending
Application number
JP2004316084A
Other languages
English (en)
Inventor
Miyuki Sakai
美由紀 酒井
Hitoshi Tanigawa
均 谷川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Toshiba Digital Solutions Corp
Original Assignee
Toshiba Corp
Toshiba Solutions Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp, Toshiba Solutions Corp filed Critical Toshiba Corp
Priority to JP2004316084A priority Critical patent/JP2006127229A/ja
Priority to US11/078,307 priority patent/US20060095456A1/en
Priority to CNA200510064601XA priority patent/CN1766875A/zh
Publication of JP2006127229A publication Critical patent/JP2006127229A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/83Querying
    • G06F16/835Query processing
    • G06F16/8373Query execution

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Document Processing Apparatus (AREA)

Abstract

【課題】指定されたノードを基点として、構造化文書データベース内を自由に親、子または兄弟ノードへ遷移して当該データベースから目的とするノードのデータを取得することができるようにする。
【解決手段】構造化文書データベース(XMLDB)11は、構造化文書を格納する。トラバース処理部14は、構造化文書検索クライアント20から、検索の基点となる基点ノードからの相対的な位置関係を指定するトラバース要求が検索要求として与えられた場合、XMLDB11内で、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従ってノードを辿ることによってデータを取得する。
【選択図】 図1

Description

本発明は、構造化文書データベース内のノードを辿って当該データベースから目的とするノードのデータを取得するのに好適な構造化文書検索システム、構造化文書検索方法及びプログラムに関する。
一般に、論理構造を持つ文書は構造化文書と呼ばれる。構造化文書において、当該文書の論理構造は、当該文書中に記述されたタグによって示される。このタグを用いて論理構造が表現された構造化文書は、コンピュータでの処理に適している。さて、タグを用いてデータを記述する手段として、XML(Extensible Markup Language)が広く利用されている。XMLは、意味付けされたタグによるデータの階層化が可能で且つ構造の自由な拡張性に富むという特長を持つ。このXMLを用いて記述された文書はXML文書と呼ばれる。XML文書は、タグを用いて論理的に木構造で表現される構造化文書の代表として知られている。
XMLの特長を生かしてXML文書を格納し、且つ当該文書中の任意の論理構造(文書構造)を検索可能とするデータベースは、XMLデータベース(XMLDB)と呼ばれる。XMLデータベースは、XPath或いはXQueryによる検索を可能とする。XPath或いはXQueryは、1つの或いは複数のXML文書中の任意の要素(ノード)を検索するためのワールド・ワイド・ウエブ・コンソーシアム(World Wide Web Consortium (W3C))によって策定された問い合わせ言語である。
例えば、XPathは、XML文書中の任意のノードの位置をルートノードからのパスによって指定することにより、当該ノードの検索を行うのに用いられる。このXPathを用いた検索をXPath検索と呼ぶ。アプリケーション(アプリケーションプログラム)は、必要なノードのパスを指定してXPath検索を行い、その検索結果からXMLデータを取得することができる。XPath検索では、検索対象のノード以下の全ての子孫ノードに対して検索を行うことも可能である。例えば、「検索対象のノード以下において、タグ名が“book”である全てのノード」といった指定が行える。この検索は、子孫ノード全てに対するパターンマッチ(一種の全文検索)であるため、検索対象ノードから実際に取得するノードまでの絶対パスを記述する必要はない。この検索を、XPathの子孫ノード検索と呼ぶ。
一方、複雑な構造を持つ文書を検索するために、特に構造化文書における兄弟関係を含む構造の検索を可能とするために、兄弟関係を木構造で表した問い合わせ木を用いることが提案されている(例えば、特許文献1参照)。つまり、特許文献1は、問い合わせ自体を木構造で表す、一種のXPath拡張技術を開示している。
特開2001−167087(段落0020乃至0026)
XMLデータベースに格納されたXML文書の一部をアプリケーションが必要とするときには、XML文書中のデータを使ってソートやフィルタリングの前処理が行われることが多い。このような場合、アプリケーションは、本来必要なデータだけでなく、前処理に用いる部分をも含めたデータを取得して、その取得されたデータを処理する必要がある。
ところが、前処理に用いる部分をも含めた必要最小限のデータだけをXpathで指定することは、一般に困難である。ここで、「“last name”(姓)が“Stevens”(スティーブンス)である“book”(書籍)の“authtor”(著者)の“first name”(名)を、“price”(書籍の値段)順に取得したい」という検索要求がある場合を想定する。また、検索対象となるXMLデータベースには、3つのXML文書が格納されており、その木構造は、後述する本発明の実施形態で参照される図7に示す3つのXML文書111,112及び113と同様であるものとする。そこで、必要ならば図7を参照されたい。まず、3つのXML文書各々の親ノード(最上位ノード)は、それぞれ「book」である。この例では、検索要求(検索条件)が複雑であり、前処理に用いる部分をも含めた必要最小限のデータだけをXpathで指定することはできない。
そこで、上記検索要求を実行するには、3つのXML文書に共通の親ノードである「book」を検索対象ノードとして、その「book」以下の全ての子孫ノードからデータを取得するための、XPathの子孫ノード検索が必要となる。しかし、XPathの子孫ノード検索では、データ取得の対象範囲が大きくなり、データ取得に多大な時間を要する。しかも、XPathの子孫ノード検索では、検索結果を取得しても途中のパスが分からず、XML文書中のどの部分がヒットしたのか分からない。
また、検索によるノード特定後のアプリケーション側の処理として、「検索されたノードの1つ下の階層のデータ」等の、検索されたノードからの相対的な位置関係を基にしたデータ取得要求も多い。ところが、XPathの子孫ノード検索では、検索されたノード周辺のパスが分からないため、検索を続けることができない。
一方、上記特許文献1に記載された問い合わせ木(XPath拡張技術)を適用した文書検索では、通常のXPath検索と異なって兄弟関係にあるノードを検索することが可能である。しかし特許文献1に記載された問い合わせ木では、階層が異なるノードなど、兄弟関係よりも複雑な関係にあるノードを検索することはできない。したがって特許文献1に記載された技術においても、上述の前処理に用いる部分をも含めたデータの検索のためには、XPathの子孫ノード検索が必要となり、データ取得の対象範囲が大きくなるという問題を解消することはできない。
本発明は上記事情を考慮してなされたものでその目的は、指定されたノードを基点として、構造化文書データベース内を自由に親、子または兄弟ノードへ遷移して当該データベースから目的とするノードのデータを取得することができる、構造化文書検索システム、構造化文書検索方法及びプログラムを提供することにある。
本発明の1つの観点によれば、構造化文書検索システムが提供される。このシステムは、構造化文書を格納する構造化文書データベースと、クライアントから、検索の基点となる基点ノードからの相対的な位置関係を指定するトラバース要求が検索要求として与えられた場合、上記構造化文書データベース内で、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従ってノードを辿ることによってデータを取得するトラバース処理手段とを備える。
このような構成の構造化文書システムにおいては、クライアントから当該システムに対して、検索の基点となる基点ノードからの相対的な位置関係を指定するトラバース要求が検索要求として与えられるだけで、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従って構造化文書データベース内のノードを辿ってデータを取得することができる。このように、構造化文書システムにおいては、XPathに代表される問い合わせ言語では指定することができない複雑な検索条件のデータ検索を、基点ノードと当該基点ノードからの相対的な位置関係が指定されるだけで実行できる。つまり、構造化文書データベース内の全てのノードを自由に辿ることができる。
ここで、XPathに代表される問い合わせ言語を用いた、従来から知られている検索要求、即ち検索の対象となるノードへのパスを検索条件として含むパス指定検索要求を実行する検索処理手段を追加し、パス指定検索要求とトラバース要求の両検索要求が実行可能な構成とすると良い。
このような構成において、クライアントは、パス指定検索要求によってターゲットとなるノードのデータを取得すると共に、当該ターゲットとなるノードの近傍のノードのデータ、つまり複雑な検索におけるソート或いはフィルタリングの条件となるノードのデータを、当該ターゲットとなるノードの近傍のノードへのパスが不明でも、トラバース要求によって簡単に取得することができる。この場合、パス指定検索要求によって検索されたノードを、トラバース要求で指定される基点ノードとすると良い。
また、構造化文書データベースが、複数の構造化文書を1つの仮想的な構造化文書の部分木として格納する構成とするならば、当該データベース内のノードを辿ることにより、複数の文書にまたがってデータを取得することができる。つまり、データベース内の全てのノードを親子兄弟の相対関係に基づいて自由に辿ることができるため、複数文書の横断検索や必要データのみの取り出しなど、データベース内での位置を示すパス記述を用いない検索ができる。
本発明によれば、クライアントから当該システムに対して、検索の基点となる基点ノードからの相対的な位置関係を指定するトラバース要求が検索要求として与えられるだけで、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従って構造化文書データベース内のノードを辿ることができるため、当該データベース内を自由に親、子または兄弟ノードへ遷移して当該データベースから目的とするノードのデータを取得することができる。
以下、本発明の一実施形態につき図面を参照して説明する。
図1は本発明の一実施形態に係るトラバース機能を持つ構造化文書検索システム10の構成を示すブロック図である。この構造化文書検索システム10は、構造化文書検索クライアント20と、ローカルエリアネットワーク(LAN)等のネットワーク21を介して接続されている。構造化文書検索クライアント(構造化文書検索クライアント端末)20上では、構造化文書検索システム10を利用するアプリケーションが動作する。構造化文書検索システム10は、XMLデータベース(XMLDB)11と、要求処理部12と、検索処理部13と、トラバース処理部14と、アプリケーションインタフェース(API)15から構成される。
XMLDB11は、構造化文書としてのXML文書を格納するデータベースである。要求処理部12は、構造化文書検索クライアント20からの検索要求を受け付ける。検索処理部13は、要求処理部12によって受け付けられた検索要求が、検索の対象となるノードへのパスを検索条件として含むXPath検索要求(つまりパス指定検索要求)の場合に、XPathに従ってXMLDB11を対象とする検索処理を行う。
トラバース処理部14は、要求処理部12によって受け付けられた検索要求が、検索の基点となる基点ノードに対する相対的な位置関係を示す方向情報により当該基点ノードに対する親子兄弟いずれかのノードを検索の対象として指定するトラバース要求の場合に、XMLDB11を対象に親子兄弟関係に基づいて木構造のノードを辿る処理を行う。この処理をトラバース処理と呼ぶ。API15は、構造化文書検索クライアント20上で動作するアプリケーションと構造化文書検索システム10とのインタフェースをなす。なお、構造化文書検索クライアント20が構造化文書検索システム10とネットワークを介さずに直接接続されている場合、API15が構造化文書検索クライアント20に設けられていても構わない。
要求処理部12、検索処理部13、トラバース処理部14及びAPI15は、コンピュータ、例えばデータベースサーバコンピュータにインストールされた特定のソフトウェアプログラム(例えば構造化文書データベース管理プログラム)を当該コンピュータ(内のCPU)が読み取って実行することにより実現される。このプログラムは、コンピュータで読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してダウンロード(頒布)されても構わない。
図2は、XMLDB11におけるXML文書格納の概念図である。図2の例では、XMLDB11に3つのXML文書111,112及び113が格納されている。ここで、XML文書111,112及び113が、いずれも、“bib”と呼ぶノードをルートとする木構造の部分木として格納されていることに注意されたい。つまり、XMLDB11には、木構造を有する1つの仮想的なXML文書110が格納され、実際のXML文書111,112及び113は当該XML文書110の部分木として管理される。“bib”ノードは、XML文書110の最上位ノード、つまりルートノードである。XML文書111,112及び113のうちの例えばXML文書111は、当該XML文書111の最上位ノード(“book”ノード)が“bib”ノードと親子関係となるように関連付けられる。ここでは、bib”ノードが親ノードとなり、XML文書111の最上位ノード(“book”ノード)が子ノードとなる。このことは、“bib”ノードとXML文書112及び113の最上位ノードとの間についても同様である。また、XML文書111,112及び113の各々の最上位ノードの間は兄弟関係となるように関連付けられる。ここでは、XML文書111,112及び113の順番でXMLDB11に格納されるものとすると、XML文書112の最上位ノードはXML文書111の最上位ノードの弟ノードに、XML文書113の最上位ノードはXML文書112の最上位ノードの弟ノードになる。これにより、XML文書111,112及び113の各ノード(要素)は、XMLDB11における仮想的なXML文書110の木構造のノードを構成する。
図3は、図2に示すXML文書111,112及び113のうちのXML文書111がXMLDB11に格納された時点における、当該XMLDB11のデータ構造例を示す。この段階では、XML文書111はXML文書110の唯一の部分木となる。図3に示されるように、XMLDB11には、XML文書110の木構造を、当該木構造を構成するノード(要素)単位で管理する構造情報テーブル31と、当該XML文書110の各ノード(要素)の情報を管理するノード情報ブロック32とが格納される。構造情報テーブル31のエントリ数及びノード情報ブロック32の数は、XML文書110のノード数に一致する。各ノードには、一意の番号であるノードIDが付与される。
構造情報テーブル31のi番目(i=1,2,…)のエントリは、ノードiのノードID(ID=i)、当該ノードiの親ノードのノードID、当該ノードiの兄ノードのノードID、当該ノードiの弟ノードのノードID、及び当該ノードiの子ノードのノードIDを、それぞれ設定するノードIDフィールド(項目)311、親ノードフィールド312、兄ノードフィールド313、弟ノードフィールド314及び子ノードフィールド315から構成される。つまり、構造情報テーブル31の各エントリは、対応するノードの木構造における位置関係を示す情報を保持するのに用いられる。なお、ノードiに、親ノード、兄ノード、弟ノードまたは子ノードが存在しない場合、構造情報テーブル31におけるi番目のエントリの対応するフィールドには、該当するノードが存在しないことを示す特定の値が設定される(図3では、“−”で示されている)。
本実施形態では、ノードiに子ノードが複数存在する場合、構造情報テーブル31におけるi番目のエントリの子フィールド315には、長男のノードのノードIDのみが設定される。例えば、ノードIDが2の“book”ノードの子ノードは、ノードIDが3,4,5及び6の、それぞれ“title”ノード、“author”ノード、“publisher”ノード及び“price”ノードであり、ノードIDが3の“title”ノードが長男である。この場合、構造情報テーブル31における2番目のエントリの子ノードフィールド315には、“title”ノードのノードID(=3)が設定される。
一方、ノード情報ブロック32は、対応するノードに固有の情報(ノード情報)を保持するのに用いられる。ここでは、ノード情報ブロック32は、ノードIDと、当該ノードのタグ名と、当該ノードの値(要素値)とを保持する。なお、ノードの値のサイズは、ノード毎に大きく異なる可能性がある。そこで、ノード情報ブロック32のサイズを一定とするために、ノードの値を当該ブロック32から切り離して保持し、当該ブロック32にはノードの値を保持している領域を指すポインタが保持される構成としても良い。
上述した構造情報テーブル31のエントリの情報、及び当該エントリに対応するノード情報ブロック32は、XML文書をXMLDB11に格納する際に作成される。このように本実施形態では、XML文書を、テキスト形式のまま、或いはシステム独自のバイナリ形式で、XMLDB11に格納するのではないことに注意されたい。即ち本実施形態では、XML文書を“bib”ノードをルートとする木構造の部分木として、当該XML文書の各ノード(要素)の当該木構造における位置関係を示す情報(構造情報)と、当該XML文書の各ノードに固有の情報(ノード情報)とが、XMLDB11に格納される。但し、このXML文書に関する構造情報とノード情報がXMLDB11に格納されることを、説明の簡略化のために、XML文書がXMLDB11に格納されると表現することもある。
図4は、図2に示すXML文書111,112及び113が、当該XML文書111,112及び113の順番で全てXMLDB11に格納された時点における、当該XMLDB11のデータ構造例を示す。ここでは、XML文書112及び113は、XML文書111と共通の木構造を有しており、当該XML文書112及び113の最上位ノードは“book”ノードである。XML文書112及び113の“book”ノードには、図4に示すように、ノードIDとして、それぞれ14及び26が付与されている。ここで、ノードIDが14の“book”ノードは、ノードIDが2の“book”ノードの弟ノードとなり、ノードIDが26の“book”ノードは、ノードIDが14の“book”ノードの弟ノードとなる。したがって、ノードIDが2の“book”ノードに対応する、構造情報テーブル31の2番目のエントリにおける弟フィールド314は、弟ノードなしを示す状態“−”から(図3参照)、ノードIDが14のノード(“book”ノード)を弟ノードとして示す状態に更新される。また、XML文書112をXML文書110の部分木としてXMLDB11に格納する際に、構造情報テーブル31には、当該XML文書112のノード数に一致する数のエントリ、例えば12個のエントリが追加される。同様に、XML文書113をXML文書110の部分木としてXMLDB11に格納する際に、構造情報テーブル31には、当該XML文書113のノード数に一致する数のエントリ、例えば12個のエントリが追加される。
次に、図1に示す構造化文書検索システム10における、トラバース処理を含む検索処理について、図5乃至図7を参照して説明する。なお、図5は構造化文書検索システム10における、トラバース処理を含む検索処理の手順を示すフローチャート、図6は構造化文書検索クライアント20と構造化文書検索システム10との間の動作手順を示すシーケンスチャート、図7はXML文書111,112及び113を木構造の部分木とする1つの仮想的なXML文書110を対象とするトラバース処理の例を示す図である。
まず、利用者から構造化文書検索クライアント20に対して、「“last name”が“Stevens”である“book”の“authtor”の“first name”を、“price”順に取得する」という検索(問い合わせ)が要求されたものとする。前述したように、この検索要求を満足する必要最小限のデータだけをXPathで指定することはできない。
そこで、構造化文書検索クライアント20はまず、“book”の“authtor”の“first name”を検索するために、以下に示すXPath
XPath = /bib/book/author/first
を生成する。クライアント20は、このXPathによる検索要求(XPath検索要求)601を構造化文書検索システム10に対して発行する。このXPath検索要求601は構造化文書検索システム10のAPI15で受け取られて、要求処理部12に渡される。このように本実施形態では、XMLDB11から必要なデータを検索することを要求するための問い合わせ言語としてXPathが用いられる。しかし、XQueryを問い合わせ言語として用いても構わない。
要求処理部12は、クライアント20からの検索要求を受け付ける。この例のように、クライアント20からの検索要求がXPath検索要求601の場合、要求処理部12は当該検索要求601を検索処理部13に渡す。すると検索処理部13は、要求処理部12から渡された検索要求601で指定されるXPath検索を実行する(ステップS1)。検索処理部13は、このXPath検索により、その検索結果(XPath検索結果)602として、XPathで指定されたノード(つまり“first”ノード)のノード情報を取得する(ステップS2)。ステップS2で取得される“first”ノードのノード情報は、当該“first”ノードのノードIDと、当該“first”ノードの子ノードの値、つまり“first name”を含むものとする。但し、検索された“first”ノードの中には、利用者からの検索要求に合致しないノードが含まれている可能性がある。そこで、ステップS2で取得される“first”ノードのノード情報に当該“first”ノードの子ノードの値が含まれないようにしても構わない。この場合、構造化文書検索クライアント20は、利用者からの検索要求に合致することが判明した“first”ノードについてのみ、その子ノードの値(つまり“first name”)を、当該“first”ノードのノード情報に含まれているノードIDを用いて、構造化文書検索システム10に要求すれば良い。
さて、図7の例では、ステップS2において、XML文書111,112及び113の“first”ノード(つまり、ノードIDがそれぞれ9,21及び33のノード)のノード情報が取得される。図7から明らかなように、ノードID=9の“first”ノードのノード情報は、ノードID=9の他に、その子ノードの値(つまり“first name”)である“W.”を含む。また、ノードID=21の“first”ノードのノード情報は、ノードID=21の他に、その子ノードの値(“first name”)である“W.”を含む。また、ノードID=33の“first”ノードのノード情報は、ノードID=33の他に、その子ノードの値(“first name”)である“Darcy”を含む。検索処理部13は、このXPath検索結果(XPath検索結果集合)602としての、検索された全ノードのノード情報を、トラバース処理部14によるトラバース処理の基点となるノードのノード情報として、要求処理部12及びAPI15を介して構造化文書検索クライアント20に返す(ステップS3)。
構造化文書検索クライアント20は、XPath検索結果602、即ちトラバース処理の基点となる“first”ノード(つまり、ノードIDがそれぞれ9,21及び33のノード)のノード情報を受け取ると、フィルタリングの条件である“last”ノードの情報とソートの条件である“price”ノードの情報とを取得するために、以下に述べるトラバース要求(トラバースコマンド)と呼ぶ特定の検索要求を利用する。トラバース要求は、現在の基点ノードのノードIDとトラバース方向を示す情報との対を含む。本実施形態において、トラバース要求で指定可能なトラバース方向は、親、兄、弟及び子の中から選択された1つである。つまり、トラバース要求は、現在の基点ノードから親ノード、兄ノード、弟ノードまたは子ノードへのトラバースを指示することができる。このようにトラバース要求は、XMLDB11に格納されている1つの仮想的なXML文書110の論理構造を表す木構造における絶対位置の指定(パスを用いた位置指定)ではなくて、基点ノードに対する親ノード、兄ノード、弟ノードまたは子ノードといった相対位置の指定を適用する。
本実施形態では、構造化文書検索システム10から構造化文書検索クライアント20に通知される、トラバース処理の基点となるノードは、ノードIDがそれぞれ9,21及び33の“first”ノードである。そこで、構造化文書検索クライアント20は、これらのノードIDがそれぞれ9,21及び33の“first”ノードを基点として、以下に述べるように構造化文書検索システム10に対して逐次トラバース処理を要求する。
“last”ノードは、現在の基点ノードである“first”ノードから見て兄ノードである。現在の基点ノードは、上記したようにノードIDがそれぞれ9,21及び33の“first”ノードである。そこで構造化文書検索クライアント20はまず、ノードIDが9の“first”ノードを基点に、兄ノードへのトラバースを指示するトラバース要求(トラバースコマンド)603を構造化文書検索システム10に発行する。この兄ノードへのトラバースを指示する要求を“get Previous Sibling”コマンドと呼ぶ。なお、図6では、トラバース要求によって指定される現在の基点ノードとトラバース方向が、(現在の基点ノードのノードID,トラバース方向)の形式で表されている。
構造化文書検索システム10の要求処理部12は、XPath検索結果602が構造化文書検索クライアント20に返されると、構造化文書検索クライアント20からの次の検索要求としてトラバース要求を待つ(ステップS4)。もし、構造化文書検索クライアント20からトラバース要求が発行された場合(ステップS5)、要求処理部12は当該トラバース要求を受け付けてトラバース処理部14に渡す。トラバース処理部14は、このトラバース要求を解釈して、基点ノードからのトラバース方向が、つまりトラバース要求ノードが、親ノード、兄ノード、弟ノードまたは子ノードのいずれであるかを判定する(ステップS6)。
もし、トラバース要求ノードが親ノードであるならば、トラバース処理部14は、トラバース要求で指定された基点ノードに対応する構造情報テーブル31内のエントリを参照し、当該エントリの親ノードフィールド312から当該基点ノードの親ノードのノードIDを取得する(ステップS7)。これに対し、トラバース要求ノードが兄ノードであるならば、トラバース処理部14は、トラバース要求で指定された基点ノードに対応する構造情報テーブル31内のエントリを参照し、当該エントリの兄ノードフィールド313から当該基点ノードの兄ノードのノードIDを取得する(ステップS8)。また、トラバース要求ノードが弟ノードであるならば、トラバース処理部14は、トラバース要求で指定された基点ノードに対応する構造情報テーブル31内のエントリを参照し、当該エントリの弟フィールド314から当該基点ノードの弟ノードのノードIDを取得する(ステップS9)。また、トラバース要求ノードが子ノードであるならば、トラバース処理部14は、トラバース要求で指定された基点ノードに対応する構造情報テーブル31内のエントリを参照し、当該エントリの子フィールド315から当該基点ノードの子ノードのノードIDを取得する(ステップS10)。次にトラバース処理部14は、取得されたノードIDに固有のノード情報ブロック32を参照して、当該ノードIDで指定されるノードのノード情報を取得する(ステップS11)。ここでは、取得されたノードIDのノードが値を持たず、且つ、その子ノードが値を持つ場合には、その値もノード情報として取得される。
構造化文書検索クライアント20から構造化文書検索システム10に対して発行されたトラバース要求603は、ノードIDが9の“first”ノードを基点に、兄ノードへのトラバースを指示している。ノードIDが9の“first”ノードの兄ノードは、図7において矢印71で示されるように、ノードIDが8の“last”ノードである。したがってステップS11では、ノードIDが8の“last”ノードのノード情報がトラバース処理部14によって取得される。ここでは、ノードIDが8の“last”ノードの子ノード(ノードIDが9のノード)の値(“last name”=“Stevens”)も、“last”ノードのノード情報の一部として取得される。
トラバース処理部14は、取得されたノード情報を、トラバース要求603に対するトラバース処理(検索処理)の結果(トラバース結果)604として、要求処理部12及びAPI15を介して構造化文書検索クライアント20に返す(ステップS12)。すると要求処理部12は、構造化文書検索クライアント20からの次のトラバース要求を待つ(ステップS4)。
トラバース結果604は、“Stevens”を“last name”として含む。つまり構造化文書検索クライアント20は、ノードIDが9の“first”ノードを基点として、兄ノード(“last”ノード)を辿るためのトラバース要求を用いることで、フィルタリングの条件である“last”ノードの情報を取得することができる。この例では、構造化文書検索クライアント20は、トラバース結果604から、ノードIDが9の“first”ノードの兄ノード、つまりノードIDが8の“last”ノードが、フィルタリング条件を満たすと判定する。そこで構造化文書検索クライアント20は、ノードIDが9の“first”ノードを基点として、ソートの条件である“price”ノードの情報を取得するために、以下に述べるトラバース要求を順に発行する。まず構造化文書検索クライアント20は、ノードIDが9の“first”ノードを基点に、親ノードへのトラバースを指示するトラバース要求605を構造化文書検索システム10に発行する。この親ノードへのトラバースを指示する要求を“get Parent Node”コマンドと呼ぶ。
構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求605に応じて、ノードIDが9の“first”ノードに対応する構造情報テーブル31内の9番目のエントリを参照し、当該エントリの親フィールド312から当該ノードIDが9の“first”ノードの親ノードのノードIDを取得する(ステップS6,S7)。ここでは、図7から明らかなように、ノードIDが9の“first”ノードの親ノードは、ノードIDが4の“author”ノードである。したがってトラバース処理部14は、トラバース要求605に応じてノードID=4を取得する。トラバース処理部14は、ノードID=4に固有のノード情報ブロック32を参照して、当該ノードID=4で指定される“author”ノードのノード情報を取得する(ステップS11)。このノードID=4で指定される“author”ノードのノード情報は、ノードID=4とタグ名“author”を含む。このノード情報は、トラバース要求605に対するトラバース結果606として構造化文書検索クライアント20に返される(ステップS12)。
構造化文書検索クライアント20は、トラバース結果606を受け取ると、当該トラバース結果606に含まれているノードID=4に基づき、ノードIDが4の“author”ノードを基点に、弟ノードへのトラバースを指示するトラバース要求607を構造化文書検索システム10に発行する。この弟ノードへのトラバースを指示する要求を“get Next Sibling”コマンドと呼ぶ。
構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求607に応じて、ノードIDが4の“author”ノードに対応する構造情報テーブル31内の4番目のエントリを参照し、当該エントリの弟フィールド314から当該ノードIDが4の“author”ノードの弟ノードのノードIDを取得する(ステップS6,S9)。ここでは、図7から明らかなように、ノードIDが4の“author”ノードの弟ノードは、ノードIDが5の“publisher”ノードである。したがってトラバース処理部14は、トラバース要求607に応じてノードID=5を取得する。トラバース処理部14は、ノードID=5に固有のノード情報ブロック32を参照して、当該ノードID=5で指定される“publisher”ノードのノード情報を取得する(ステップS11)。このノードID=5で指定される“publisher”ノードのノード情報は、ノードID=5とタグ名“publisher”を含む。このノード情報は、トラバース要求607に対するトラバース結果608として構造化文書検索クライアント20に返される(ステップS12)。
構造化文書検索クライアント20は、トラバース結果608を受け取ると、当該トラバース結果608に含まれているノードID=5に基づき、ノードIDが5の“publisher”ノードを基点に、弟ノードへのトラバースを指示するトラバース要求609を構造化文書検索システム10に発行する。
構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求609に応じて、ノードIDが5のノードに対応する構造情報テーブル31内の5番目のエントリを参照し、当該エントリの弟フィールド314から当該ノードIDが5の“publisher”ノードの弟ノードのノードIDを取得する(ステップS6,S9)。ここでは、図7から明らかなように、ノードIDが5の“publisher”ノードの弟ノードは、ノードIDが6の“price”ノードである。したがってトラバース処理部14は、トラバース要求609に応じてノードID=6を取得する。トラバース処理部14は、ノードID=6に固有のノード情報ブロック32を参照して、当該ノードID=6の“price”ノードのノード情報を取得する(ステップS11)。トラバース処理部14はまた、この“price”ノードの子ノードの値(つまり“price”)である“65.95”も取得する。トラバース処理部14は、この値を“price”ノードのノード情報に含める。このノード情報は、トラバース要求609に対するトラバース結果610として構造化文書検索クライアント20に返される(ステップS12)。
このように構造化文書検索クライアント20は、ノードIDが9の“first”ノードを基点として、親ノード(“author”ノード)、当該親ノードの弟ノード(“publisher”ノード)、当該弟ノードの弟ノード(“price”ノード)と順に辿るためのトラバース要求を用いることで、ソートの条件である“price”ノードの情報を取得することができる。
次に構造化文書検索クライアント20は、ノードIDが21の“first”ノードを基点として、フィルタリングの条件である“last”ノードの情報を取得するために、以下に述べるトラバース要求611を構造化文書検索システム10に発行する。このトラバース要求611は、ノードIDが21の“first”ノードを基点に、兄ノードへのトラバースを指示する。
構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求611に応じて、ノードIDが21のノードに対応する構造情報テーブル31内のエントリを参照し、当該エントリの兄フィールド313から当該ノードIDが21のノードの兄ノードのノードIDを取得する(ステップS6,S8)。ここでは、図7から明らかなように、ノードIDが21のノードの兄ノードは、ノードIDが20の“last”ノードである。したがってトラバース処理部14は、トラバース要求611に応じてノードID=20を取得する。トラバース処理部14は、ノードID=20に固有のノード情報ブロック32を参照して、当該ノードID=20の“last”ノードのノード情報を取得する(ステップS11)。またトラバース処理部14は、この“last”ノードの子ノードの値(つまり“last name”)である“Stevens”も取得する。トラバース処理部14は、この値を“last”ノードのノード情報に含める。このノード情報は、トラバース要求611に対するトラバース結果612として構造化文書検索クライアント20に返される(ステップS12)。
上記したようにトラバース結果612は、“Stevens”を“last name”として含む。つまり構造化文書検索クライアント20は、ノードIDが21の“first”ノードを基点として、兄ノード(“last”ノード)を辿るためのトラバース要求を用いることで、フィルタリングの条件である“last”ノードの情報を取得することができる。この例では、構造化文書検索クライアント20は、トラバース結果612から、ノードIDが21の“first”ノードの兄ノード、つまりノードIDが22の“last”ノードが、フィルタリング条件を満たすと判定する。そこで構造化文書検索クライアント20は、ノードIDが21の“first”ノードを基点として、ソートの条件である“price”ノードの情報を取得するために、以下に述べるトラバース要求を順に発行する。まず構造化文書検索クライアント20は、ノードIDが21の“first”ノードを基点に、親ノードへのトラバースを指示するトラバース要求613を構造化文書検索システム10に発行する。
構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求613に応じて構造情報テーブル31を参照することにより、先のトラバース要求605と同様にして、ノードIDが21の“first”ノードの親ノードのノードIDを取得する(ステップS6,S7)。ノードIDが21の“first”ノードの親ノードは、図7において矢印72で示されるように、ノードIDが16の“author”ノードである。したがってトラバース処理部14は、トラバース要求613に応じてノードID=16を取得する。そしてトラバース処理部14は、ノードID=16で指定される“author”ノードのノード情報を取得する(ステップS11)。この“author”ノードのノード情報は、ノードID=16とタグ名“author”を含む。このノード情報は、トラバース要求613に対するトラバース結果614として構造化文書検索クライアント20に返される(ステップS12)。
構造化文書検索クライアント20は、トラバース結果614を受け取ると、当該トラバース結果614に含まれているノードID=16に基づき、ノードIDが16の“author”ノードを基点に、弟ノードへのトラバースを指示するトラバース要求615を構造化文書検索システム10に発行する。構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求615に応じて構造情報テーブル31を参照することにより、先のトラバース要求607と同様にして、ノードIDが16の“author”ノードの弟ノードのノードIDを取得する(ステップS6,S9)。ノードIDが16の“author”ノードの弟ノードは、図7において矢印73で示されるように、ノードIDが17の“publisher”ノードである。したがってトラバース処理部14は、トラバース要求615に応じてノードID=17を取得する。そしてトラバース処理部14は、ノードID=17で指定される“publisher”ノードのノード情報を取得する(ステップS11)。この“publisher”ノードのノード情報は、ノードID=17とタグ名“publisher”を含む。このノード情報は、トラバース要求615に対するトラバース結果616として構造化文書検索クライアント20に返される(ステップS12)。
構造化文書検索クライアント20は、トラバース結果616を受け取ると、当該トラバース結果616に含まれているノードID=17に基づき、ノードIDが17の“publisher”ノードを基点に、弟ノードへのトラバースを指示するトラバース要求617を構造化文書検索システム10に発行する。構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求617に応じて構造情報テーブル31を参照することにより、先のトラバース要求609と同様にして、ノードIDが17の“publisher”ノードの弟ノードのノードIDを取得する(ステップS6,S9)。ノードIDが17の“publisher”ノードの弟ノードは、図7において矢印74で示されるように、ノードIDが18の“price”ノードである。したがってトラバース処理部14は、トラバース要求617に応じてノードID=18を取得する。そしてトラバース処理部14は、ノードID=18の“price”ノードのノード情報を取得する(ステップS11)。トラバース処理部14はまた、この“price”ノードの子ノードの値(つまり“price”)である“85.95”も取得する。トラバース処理部14は、この値を“price”ノードのノード情報に含める。このノード情報は、トラバース要求617に対するトラバース結果618として構造化文書検索クライアント20に返される(ステップS12)。
このように構造化文書検索クライアント20は、ノードIDが21の“first”ノードを基点として、親ノード(“author”ノード)、当該親ノードの弟ノード(“publisher”ノード)、当該弟ノードの弟ノード(“price”ノード)と順に辿るためのトラバース要求を用いることで、ソートの条件である“price”ノードの情報を取得することができる。
次に構造化文書検索クライアント20は、ノードIDが33の“first”ノードを基点として、フィルタリングの条件である“last”ノードの情報を取得するために、以下に述べるトラバース要求619を構造化文書検索システム10に発行する。このトラバース要求619は、ノードIDが33の“first”ノードを基点に、兄ノードへのトラバースを指示する。
構造化文書検索システム10のトラバース処理部14は、構造化文書検索クライアント20からのトラバース要求619に応じて構造情報テーブル31を参照することにより、先のトラバース要求603と同様にして、ノードIDが33の“first”ノードの兄のノードIDを取得する(ステップS6,S8)。ここでは、図7から明らかなように、ノードIDが33のノードの兄ノードは、ノードIDが32の“last”ノードである。したがってトラバース処理部14は、トラバース要求619に応じてノードID=32を取得する。トラバース処理部14は、ノードID=32に固有のノード情報ブロック32を参照して、当該ノードID=32の“last”ノードのノード情報を取得する(ステップS11)。またトラバース処理部14は、この“last”ノードの子ノードの値(つまり“last name”)である“Gerberg”も取得する。トラバース処理部14は、この値を“last”ノードのノード情報に含める。このノード情報は、トラバース要求619に対するトラバース結果620として構造化文書検索クライアント20に返される(ステップS12)。
このように、トラバース結果620は、“Gerberg”を“last name”として含む。つまりトラバース結果620は、“Stevens”を“last name”として含んでいない。この場合、構造化文書検索クライアント20は、トラバース結果620から、ノードIDが33の“first”ノードの兄ノード、つまりノードIDが32の“last”ノードが、フィルタリング条件を満たしていないと判定する。そこで構造化文書検索クライアント20は、トラバース要求の発行を終了する。構造化文書検索システム10の要求処理部12は、トラバース要求の待ち状態となってから(ステップS4)、例えば一定期間を超えて構造化文書検索クライアント20からトラバース要求が発行されない場合(ステップS5)、構造化文書検索システム10におけるトラバース処理を終了する。なお、構造化文書検索クライアント20から処理の終了が通知された場合にも、要求処理部12は構造化文書検索システム10におけるトラバース処理を終了する。
このように本実施形態においては、XPathを用いた検索の結果(XPath検束結果)で示される全てのノードの各々について、そのノードを基点として、XMLDB11内で1つの仮想的なXML文書110の部分木として管理されている、実際のXML文書の木構造上で、親子兄弟ノードを自由に辿るトラバース処理を実現できる。このトラバース処理により、ソートやフィルタリング処理に必要な最小限のデータのみの検索が可能である。
また、実際のXML文書、即ちXML文書111,112及び113は、XMLDB11内では、図4及び図7からも明らかなように、1つの仮想的なXML文書110の部分木として管理される。したがって、上述したXML文書111,112及び113の各々の木構造(部分木)内だけでなく、図7において矢印75乃至78で示されるように、XPath検索によって特定された基点ノード(ここでは、ノードIDが33の“first”ノード)を基点に、トラバース処理によって文書から文書へと辿ることができる。つまり、1つの仮想的なXML文書110の部分木として管理される複数の実XML文書に渡る横断的な検索を行うことができる。この図7の例では、XML文書113の“book”ノードから“bib”ノードを介してXML文書112の“book”ノードを辿る様子が示されている。しかし、XML文書113の“book”ノードから兄ノードへのトラバースを要求することで、XML文書113の“book”ノードからXML文書112の“book”ノードを直接辿ることもできる。
ところで、XMLには、“タグ”(要素)の“属性”という概念がある。この“属性”(属性ノード)は、XMLまたはDOM(Document Object Model)の分野では、通常、“タグ”(タグノード)と異なって、親子兄弟といった関係とは切り離される。しかし、例えば図2に示したような以下のXML文書
<book year=“1965”>
<title>……</title>
<author>……</author>

において、“book”ノードの属性である“year”ノードも、“title”ノードや“author”ノードといったタグノードと同様に、“book”ノードの子ノードの1つと考えることができる。そこで、属性ノードを、当該属性ノードに対応するタグノードの子ノード(例えば長男のノード)と見なすことにより、当該属性ノードもタグノードと全く同様に扱うことができる。
上記実施形態では、説明を簡略化するために、XML文書111,112及び113の木構造が共通であることを前提としている。しかし本実施形態におけるトラバース処理では、現在の基点ノードに対する、親ノード、子ノードといった相対的な位置情報で、トラバース先(検索対象)が指定されるため、パスの記述を意識することなく縦横にXMLDB11を走査することができる。そのため、XML文書111,112及び113の木構造が共通でなく、パスが不明であっても、XPsth検索で検索されたノードの近傍の検索を行うことができる。
また上記実施形態では、構造化文書検索クライアント20から構造化文書検索システム10に対して逐次トラバース要求が発行される。しかし、XML文書111,112及び113の木構造が構造化文書検索クライアント20側で予め分かっている場合には、
構造化文書検索クライアント20から構造化文書検索システム10に対し、更に具体的に述べるならば構造化文書検索クライアント20からAPI15に対し、1回だけトラバース要求が発行される構成とすることも可能である。ここでは、XPath検索(XQuery検索)で検索されたノードのノードIDを基点ノードのノードIDとし、当該基点ノードのノードIDと、当該基点ノードを基点としてXMLDB11内を辿る方向の組み合わせだけを、トラバース要求によって構造化文書検索クライアント20からAPI15に通知すれば良い。以後、API15が、構造化文書検索クライアント20からのトラバース要求に従って、上記実施形態におけるトラバース要求603,605及び607等に相当するトラバース要求を逐次要求処理部12に発行すれば良い。
上記実施形態では、XML文書111,112及び113の最上位ノード(“book”ノード)が、仮想的なXML文書110の最上位ノード(“bib”ノード)の子ノードとして管理される。しかし、XMLDB11に格納される実際のXML文書を、例えば文書種類毎に分類し、その文書種類に固有のノードを“bib”ノードの子ノードとして管理すると共に、その文書種類に属するXML文書の最上位ノードを、その文書種類に固有のノードの子ノードとして管理しても良い。このようにすると、同一の文書種類に属する複数のXML文書の横断検索をより効率的に行うことができる。更に、文書種類を、例えば大分類、中分類及び小分類に分け、それぞれ対応する大分類ノード、中分類ノード及び小分類ノードを用意しても良い。この場合、XML文書を、“bib”ノード−大分類ノード−中分類ノード−小分類ノード−XML文書の最上位ノードといった木構造の部分木として管理できる。
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除しても良い。
本発明の一実施形態に係るトラバース機能を持つ構造化文書検索システム10の構成を示すブロック図。 XMLDB11におけるXML文書格納の概念図。 図2に示すXML文書111,112及び113のうちのXML文書111がXMLDB11に格納された時点における、当該XMLDB11のデータ構造例を示す図。 図2に示すXML文書111,112及び113が、当該XML文書111,112及び113の順番で全てXMLDB11に格納された時点における、当該XMLDB11のデータ構造例を示す図。 構造化文書検索システム10における、トラバース処理を含む検索処理の手順を示すフローチャート。 構造化文書検索クライアント20と構造化文書検索システム10との間の動作手順を示すシーケンスチャート。 XML文書111,112及び113を木構造の部分木とする1つの仮想的なXML文書110を対象とするトラバース処理の例を示す図。
符号の説明
10…構造化文書検索システム、11…XMLDB(XMLデータベース、構造化文書データベース)、12…要求処理部、13…検索処理部、14…トラバース処理部、15…API(アプリケーションインタフェース)、20…構造化文書検索クライアント、31…構造情報テーブル、32…ノード情報ブロック。

Claims (12)

  1. 構造化文書を格納する構造化文書データベースと、
    クライアントから、検索の基点となる基点ノードからの相対的な位置関係を指定するトラバース要求が検索要求として与えられた場合、前記構造化文書データベース内で、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従ってノードを辿ることによってデータを取得するトラバース処理手段と
    を具備することを特徴とする構造化文書検索システム。
  2. 前記トラバース要求は、基点ノードからの相対的な位置関係を示す方向情報により当該基点ノードに対する親子兄弟いずれかのノードを検索の対象として指定し、前記トラバース処理手段は、当該トラバース要求で指定された基点ノードから前記方向情報の指定する親子兄弟いずれかのノードを辿ることを特徴とする請求項1記載の構造化文書検索システム。
  3. 前記クライアントから、検索の対象となるノードへのパスを検索条件として含むパス指定検索要求が与えられた場合、前記構造化データベースから当該パスで指定されるノードを検索してデータを取得する検索処理手段を更に具備することを特徴とする請求項1記載の構造化文書検索システム。
  4. 前記トラバース要求が、前記検索要求に応じて検索されたノードを新たな検索の基点となる基点ノードとして指定することを特徴とする請求項3記載の構造化文書検索システム。
  5. 前記クライアントからの検索要求を受け付けて、当該検索要求が前記トラバース要求または前記パス指定検索要求のいずれであるかを判定し、当該検索要求が前記トラバース要求の場合には、当該検索要求を前記トラバース処理手段に渡し、当該検索要求が前記パス指定検索要求の場合には、当該検索要求を前記検索処理手段に渡す要求処理手段を更に具備することを特徴とする請求項3記載の構造化文書検索システム。
  6. 前記構造化文書データベースは、複数の構造化文書を1つの仮想的な構造化文書の部分木として格納する請求項1記載の構造化文書検索システム。
  7. 前記構造化文書データベースは、前記仮想的な構造化文書の木構造の要素となる各ノードの親子兄弟関係を管理する構造情報を格納し、
    前記トラバース処理手段は、前記構造情報に従って前記トラバース要求の指定するノードを辿る
    ことを特徴とする請求項6記載の構造化文書検索システム。
  8. 構造化文書を格納する構造化文書データベースから検索要求で指定されたノードを検索する構造化文書検索方法であって、
    クライアントから、検索の対象となるノードへのパスを検索条件として含むパス指定検索要求が与えられた場合、前記構造化データベースから当該パスで指定されるノードを検索するステップと、
    検索されたノードのデータを前記パス指定検索要求に対する検索結果として前記クライアントに返すステップと、
    前記検索結果によって示されるノードを新たな検索の基点となる基点ノードとして、当該基点ノードからの相対的な位置関係を指定するトラバース要求が前記クライアントから検索要求として与えられた場合、前記構造化文書データベース内で、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従ってノードを辿るトラバース処理を実行するステップと、
    トラバース処理によって検索されたノードのデータを前記トラバース要求に対する検索結果として前記クライアントに返すステップと
    を具備することを特徴とする構造化文書検索方法。
  9. 前記トラバース要求は、基点ノードからの相対的な位置関係を示す方向情報により当該基点ノードに対する親子兄弟いずれかのノードを検索の対象として指定し、
    前記トラバース処理を実行するステップは、前記方向情報に従って、前記トラバース要求で指定された基点ノードから辿るべきノードが、親子兄弟のうちのいずれであるかを判定するステップを含む
    ことを特徴とする請求項8記載の構造化文書検索方法。
  10. 前記構造化文書データベースは、複数の構造化文書を1つの仮想的な構造化文書の部分木として格納することを特徴とする請求項9記載の構造化文書検索システム。
  11. 前記構造化文書データベースは、前記仮想的な構造化文書の木構造の要素となる各ノードの親子兄弟関係を管理する構造情報を格納し、
    前記トラバース処理を実行するステップは、前記トラバース要求で指定された基点ノードから辿るべきノードを、当該基点ノードと前記判定するステップでの判定結果と前記構造情報とに基づいて特定するステップを含む
    ことを特徴とする請求項10記載の構造化文書検索方法。
  12. 構造化文書を格納する構造化文書データベースから検索要求で指定されたノードを検索するためのプログラムであって、
    コンピュータに、
    クライアントから、検索の対象となるノードへのパスを検索条件として含むパス指定検索要求が与えられた場合、前記構造化データベースから当該パスで指定されるノードを検索するステップと、
    検索されたノードのデータを前記パス指定検索要求に対する検索結果として前記クライアントに返すステップと、
    前記検索結果によって示されるノードを新たな検索の基点となる基点ノードとして、当該基点ノードからの相対的な位置関係を指定するトラバース要求が前記クライアントから検索要求として与えられた場合、前記構造化文書データベース内で、当該トラバース要求で指定された基点ノードから当該トラバース要求で指定された相対的な位置関係に従ってノードを辿るトラバース処理を実行するステップと、
    トラバース処理によって検索されたノードのデータを前記トラバース要求に対する検索結果として前記クライアントに返すステップと
    を実行させるためのプログラム。
JP2004316084A 2004-10-29 2004-10-29 構造化文書検索システム、構造化文書検索方法及びプログラム Pending JP2006127229A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004316084A JP2006127229A (ja) 2004-10-29 2004-10-29 構造化文書検索システム、構造化文書検索方法及びプログラム
US11/078,307 US20060095456A1 (en) 2004-10-29 2005-03-14 System and method for retrieving structured document
CNA200510064601XA CN1766875A (zh) 2004-10-29 2005-04-15 用于检索结构化文件的系统和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004316084A JP2006127229A (ja) 2004-10-29 2004-10-29 構造化文書検索システム、構造化文書検索方法及びプログラム

Publications (1)

Publication Number Publication Date
JP2006127229A true JP2006127229A (ja) 2006-05-18

Family

ID=36263322

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004316084A Pending JP2006127229A (ja) 2004-10-29 2004-10-29 構造化文書検索システム、構造化文書検索方法及びプログラム

Country Status (3)

Country Link
US (1) US20060095456A1 (ja)
JP (1) JP2006127229A (ja)
CN (1) CN1766875A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010091564A1 (zh) * 2009-02-13 2010-08-19 华为技术有限公司 一种获取节点信息的方法、服务器以及系统
JP2011076420A (ja) * 2009-09-30 2011-04-14 Toshiba Corp 構造化文書検索システム及びプログラム
JP2012008944A (ja) * 2010-06-28 2012-01-12 Hitachi Aloka Medical Ltd 診断レポート検索装置

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4373470B2 (ja) * 2005-03-30 2009-11-25 富士通株式会社 文書変換活用システム
US7523124B2 (en) * 2006-06-26 2009-04-21 Nielsen Media Research, Inc. Methods and apparatus for improving data warehouse performance
ATE429119T1 (de) * 2007-05-18 2009-05-15 Sap Ag Verfahren und system zum schutz einer nachricht vor einem xml-angriff beim austausch in einem verteilten und dezentralisierten netzwerksystem
US8650219B2 (en) 2012-06-05 2014-02-11 International Business Machines Corporation Persistent iteration over a database tree structure
CN103827861B (zh) * 2012-09-07 2017-09-08 株式会社东芝 结构化文档管理装置及方法
CN105721527B (zh) * 2014-12-04 2019-03-01 金蝶软件(中国)有限公司 一种数据处理方法以及服务器
CN106874442B (zh) * 2017-02-08 2023-08-18 三和智控(北京)系统集成有限公司 通过数据名称命名实现数据自携带特征信息的方法及装置
CN111737018B (zh) * 2020-08-26 2020-12-22 腾讯科技(深圳)有限公司 ZooKeeper配置文件存储处理方法、装置、设备及其介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2048039A1 (en) * 1991-07-19 1993-01-20 Steven Derose Data processing system and method for generating a representation for and random access rendering of electronic documents
US6381605B1 (en) * 1999-05-29 2002-04-30 Oracle Corporation Heirarchical indexing of multi-attribute data by sorting, dividing and storing subsets
JP3842577B2 (ja) * 2001-03-30 2006-11-08 株式会社東芝 構造化文書検索方法および構造化文書検索装置およびプログラム
US6925470B1 (en) * 2002-01-25 2005-08-02 Amphire Solutions, Inc. Method and apparatus for database mapping of XML objects into a relational database
WO2003107323A1 (en) * 2002-06-13 2003-12-24 Cerisent Corporation A subtree-structured xml database
US7013311B2 (en) * 2003-09-05 2006-03-14 International Business Machines Corporation Providing XML cursor support on an XML repository built on top of a relational database system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010091564A1 (zh) * 2009-02-13 2010-08-19 华为技术有限公司 一种获取节点信息的方法、服务器以及系统
JP2011076420A (ja) * 2009-09-30 2011-04-14 Toshiba Corp 構造化文書検索システム及びプログラム
JP2012008944A (ja) * 2010-06-28 2012-01-12 Hitachi Aloka Medical Ltd 診断レポート検索装置

Also Published As

Publication number Publication date
US20060095456A1 (en) 2006-05-04
CN1766875A (zh) 2006-05-03

Similar Documents

Publication Publication Date Title
JP4445509B2 (ja) 構造化文書検索システム及びプログラム
US7231386B2 (en) Apparatus, method, and program for retrieving structured documents
US8229932B2 (en) Storing XML documents efficiently in an RDBMS
US8694510B2 (en) Indexing XML documents efficiently
AU2004237062A1 (en) Retaining hierarchical information in mapping between XML documents and relational data
US7664773B2 (en) Structured data storage method, structured data storage apparatus, and retrieval method
JP4247108B2 (ja) 構造化文書検索方法、構造化文書検索装置、及びプログラム
JP2006127229A (ja) 構造化文書検索システム、構造化文書検索方法及びプログラム
US7409636B2 (en) Lightweight application program interface (API) for extensible markup language (XML)
KR101254544B1 (ko) 배열의 생성방법 및 이를 실행하는 컴퓨터 프로그램을 수록한 기록 매체
JP2009544102A (ja) Xml文書の、意味論を意識した処理
JP2006127235A (ja) 構造化文書管理システム、構造化文書管理方法及びプログラム
JP3914081B2 (ja) アクセス権限設定方法および構造化文書管理システム
JP3842572B2 (ja) 構造化文書管理方法および構造化文書管理装置およびプログラム
JP3842576B2 (ja) 構造化文書編集方法及び構造化文書編集システム
JP4724177B2 (ja) Xmlデータにアクセスするためのインデックス
JP4289022B2 (ja) 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体
JP4199916B2 (ja) 文書管理方法および装置
JP4568267B2 (ja) 構造化文書検索システム及びデータベース管理プログラム
JP3842574B2 (ja) 情報抽出方法および構造化文書管理装置およびプログラム
JP4393498B2 (ja) 構造化文書管理システム及びプログラム
JP4550876B2 (ja) 構造化文書検索システム及びプログラム
JP3842575B2 (ja) 構造化文書検索方法、構造化文書管理装置及びプログラム
JP4406397B2 (ja) 構造化文書検索システム及びプログラム
Nørvåg Query Operators in Temporal XML Databases

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070807

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071009

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080325

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080805