JP2000057163A - 構造化文書データベースシステム - Google Patents
構造化文書データベースシステムInfo
- Publication number
- JP2000057163A JP2000057163A JP10227479A JP22747998A JP2000057163A JP 2000057163 A JP2000057163 A JP 2000057163A JP 10227479 A JP10227479 A JP 10227479A JP 22747998 A JP22747998 A JP 22747998A JP 2000057163 A JP2000057163 A JP 2000057163A
- Authority
- JP
- Japan
- Prior art keywords
- document
- search
- structured
- database
- unit
- 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
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】 構造化文書に対する曖昧な条件指定からの文
書要素検索を可能とし、また曖昧な構造条件指定によっ
ても検索性能を劣化させない検索を実現する。 【解決手段】 構造化文書入力部1によりオブジェクト
指向データベース2に格納された構造化文書に対して、
曖昧な条件指定による文書要素検索を実現すべく、文書
検索式入力部3にてこの曖昧な条件指定を検索式として
表現した入力を受け入れ、文書検索式解析部4でこの条
件式を解析して構造化文書データベース2へアクセスす
るプログラムを組み立てる。文書検索部5でこのプログ
ラムを実際に実行し、プログラムの実行結果として検索
された検索要素を、検索文書表示部6にてシステム外部
へ表示する。
書要素検索を可能とし、また曖昧な構造条件指定によっ
ても検索性能を劣化させない検索を実現する。 【解決手段】 構造化文書入力部1によりオブジェクト
指向データベース2に格納された構造化文書に対して、
曖昧な条件指定による文書要素検索を実現すべく、文書
検索式入力部3にてこの曖昧な条件指定を検索式として
表現した入力を受け入れ、文書検索式解析部4でこの条
件式を解析して構造化文書データベース2へアクセスす
るプログラムを組み立てる。文書検索部5でこのプログ
ラムを実際に実行し、プログラムの実行結果として検索
された検索要素を、検索文書表示部6にてシステム外部
へ表示する。
Description
【0001】
【発明の属する技術分野】本発明は構造化文書データベ
ースシステムに関し、特にSGML(Standard Generalized
Markup Language)やXML(eXtensible Markup Language)
などに代表される構造化文書、すなわち文書型定義DTD
(Document Type Definition) と、この文書型定義に従
った文書インスタンスと、この文書インスタンスを構成
する1つ以上の文書要素を持つ構造化文書を格納・管理
して当該構造化文書に対する検索要求に応答して特定の
文書インスタンスまたは文書要素を取り出すことを可能
にするデータベースシステムを構造化文書データベース
システムと呼ぶことにすると、本発明は構造化文書デー
タベースシステムの技術分野に属する。
ースシステムに関し、特にSGML(Standard Generalized
Markup Language)やXML(eXtensible Markup Language)
などに代表される構造化文書、すなわち文書型定義DTD
(Document Type Definition) と、この文書型定義に従
った文書インスタンスと、この文書インスタンスを構成
する1つ以上の文書要素を持つ構造化文書を格納・管理
して当該構造化文書に対する検索要求に応答して特定の
文書インスタンスまたは文書要素を取り出すことを可能
にするデータベースシステムを構造化文書データベース
システムと呼ぶことにすると、本発明は構造化文書デー
タベースシステムの技術分野に属する。
【0002】また、整形式(well-formed) のXML 文書と
呼ばれる特定のDTD に従わない文書インスタンスを扱う
構造化文書データベースシステムも本発明の技術分野に
属する。データベースに格納された構造化文書に対する
論理構造及び文書内容の追加・変更・削除の各操作、ま
た論理構造及び文書内容の複数文書間での共有化を可能
にする構造化文書操作部を具備する構造化文書データベ
ースシステムも本発明の技術分野に属するが、構造化文
書操作部の実現方式に関しては本発明の範囲外とする。
呼ばれる特定のDTD に従わない文書インスタンスを扱う
構造化文書データベースシステムも本発明の技術分野に
属する。データベースに格納された構造化文書に対する
論理構造及び文書内容の追加・変更・削除の各操作、ま
た論理構造及び文書内容の複数文書間での共有化を可能
にする構造化文書操作部を具備する構造化文書データベ
ースシステムも本発明の技術分野に属するが、構造化文
書操作部の実現方式に関しては本発明の範囲外とする。
【0003】また全文検索エンジン部と前記全文検索エ
ンジンとが作成する文書インデックスを格納する文書イ
ンデックス格納部とを具備する構造化文書データベース
システムも本発明の技術分野に属するが、全文検索エン
ジン部の実現方式及び文書インデックス格納部の実現方
式に関しては本発明の範囲外とする。また文書インスタ
ンス及び文書要素を表示する検索文書表示部を具備する
構造化文書データベースシステムも本発明の技術分野に
属するが、検索文書表示部の実現方式に関しては本発明
の範囲外とする。
ンジンとが作成する文書インデックスを格納する文書イ
ンデックス格納部とを具備する構造化文書データベース
システムも本発明の技術分野に属するが、全文検索エン
ジン部の実現方式及び文書インデックス格納部の実現方
式に関しては本発明の範囲外とする。また文書インスタ
ンス及び文書要素を表示する検索文書表示部を具備する
構造化文書データベースシステムも本発明の技術分野に
属するが、検索文書表示部の実現方式に関しては本発明
の範囲外とする。
【0004】
【従来の技術】本発明の管理の対象としている構造化文
書に対して説明する。例として図3、図20を用いる。
図3は構造化文書の一構成要素である文書型定義(DTD)
の例であり、図20は構造化文書の一構成要素である文
書インスタンスの例である。文書インスタンスは文書型
定義に基づいて作成される。また文書インスタンスは複
数の文書要素(または単に要素)で構成され、図20に
示すような木構造を構成する。
書に対して説明する。例として図3、図20を用いる。
図3は構造化文書の一構成要素である文書型定義(DTD)
の例であり、図20は構造化文書の一構成要素である文
書インスタンスの例である。文書インスタンスは文書型
定義に基づいて作成される。また文書インスタンスは複
数の文書要素(または単に要素)で構成され、図20に
示すような木構造を構成する。
【0005】図3の表記法に関しては、日本ユニテック
SGMLサロン、“はじめてのSGML”、技術評論社、199
5、で用いられるDTD の木構造表記法を用いた。四角で
囲った各部分が文書要素を表し、四角の中に文書要素名
を記述する。木構造表記法では一般に最上部に位置する
要素をルート(根)要素と呼び、以下複数の子要素を持
つようなつながりで末端の葉要素まで線(辺、エッジ)
でつなぐ。ある要素の上に位置する要素はその要素の親
要素と呼び、ある要素の下に位置する要素はその要素の
子要素と呼ぶ。
SGMLサロン、“はじめてのSGML”、技術評論社、199
5、で用いられるDTD の木構造表記法を用いた。四角で
囲った各部分が文書要素を表し、四角の中に文書要素名
を記述する。木構造表記法では一般に最上部に位置する
要素をルート(根)要素と呼び、以下複数の子要素を持
つようなつながりで末端の葉要素まで線(辺、エッジ)
でつなぐ。ある要素の上に位置する要素はその要素の親
要素と呼び、ある要素の下に位置する要素はその要素の
子要素と呼ぶ。
【0006】図3の四角各以外の記号で丸の中に右矢印
がある記号は、以下の子要素が左から右の順で出現する
という順序出現を表す。要素を表す四角の記号の右上に
添えている*の記号は、当該要素が0回以上現れること
を表す。特に*がついていない要素については、当該要
素が1回出現することを表す。
がある記号は、以下の子要素が左から右の順で出現する
という順序出現を表す。要素を表す四角の記号の右上に
添えている*の記号は、当該要素が0回以上現れること
を表す。特に*がついていない要素については、当該要
素が1回出現することを表す。
【0007】図20は文書型定義で定義した要素の種別
と、出現する親子関係、出現回数の制約を基にして作成
したものである。丸で囲った各部分を文書インスタンス
中の文書要素としてその中に文書要素名を記述する。文
書要素名の後に便宜上英数字を割り振っているが、これ
は他の文書要素と区別するために振ったものであり、基
本的に文書要素名は添字の英数字を除いた部分の文字列
である。ある文書インスタンス中の文書要素の出現順序
に関しては、木構造において左深さ優先順序でならべ、
文書要素の親子関係を線でつないで木構造としている。
図20の“盲腸”や“胃潰瘍”という文字列に関して
は、それぞれ文書要素「病名1」、「病名2」の中身に
これらの文字列が含まれているということを表してい
る。
と、出現する親子関係、出現回数の制約を基にして作成
したものである。丸で囲った各部分を文書インスタンス
中の文書要素としてその中に文書要素名を記述する。文
書要素名の後に便宜上英数字を割り振っているが、これ
は他の文書要素と区別するために振ったものであり、基
本的に文書要素名は添字の英数字を除いた部分の文字列
である。ある文書インスタンス中の文書要素の出現順序
に関しては、木構造において左深さ優先順序でならべ、
文書要素の親子関係を線でつないで木構造としている。
図20の“盲腸”や“胃潰瘍”という文字列に関して
は、それぞれ文書要素「病名1」、「病名2」の中身に
これらの文字列が含まれているということを表してい
る。
【0008】文書の論理構造に基づく特定の文書要素の
指定とは、図20を例に説明すると、例えば文書の先頭
から3番目の文書要素とは、最左深さ優先順序で文書要
素「患者」となる。また「カルテ」の2番目の「記録」
の「病名」は、文書要素「病名2 」に含まれる“胃潰
瘍”となる。また1番目の「記録」の2 番目の「患者」
は論理的には存在しないように規制されている。それは
図3の文書型定義で、「記録」に含まれる「患者」はた
だ一つと定義されたからである。このように、文書型定
義の制約に従い、実際の文書インスタンスの文書要素の
木構造の関係を正しく指定すれば、すべての文書要素を
論理的構造に基づいて特定することができる。
指定とは、図20を例に説明すると、例えば文書の先頭
から3番目の文書要素とは、最左深さ優先順序で文書要
素「患者」となる。また「カルテ」の2番目の「記録」
の「病名」は、文書要素「病名2 」に含まれる“胃潰
瘍”となる。また1番目の「記録」の2 番目の「患者」
は論理的には存在しないように規制されている。それは
図3の文書型定義で、「記録」に含まれる「患者」はた
だ一つと定義されたからである。このように、文書型定
義の制約に従い、実際の文書インスタンスの文書要素の
木構造の関係を正しく指定すれば、すべての文書要素を
論理的構造に基づいて特定することができる。
【0009】構造化文書に関する発明としては、構造化
文書データベースシステムに関する発明が過去数件公開
されており、特開平5−225240号公報では、文書
データベースに蓄積されている構造化文書から一部分の
文書内容を抽出する文書データベース装置に関するもの
である。この発明は上述の「発明の属する分野」で定義
した構造化文書データベースシステムの一部を構成する
基本的な技術である。
文書データベースシステムに関する発明が過去数件公開
されており、特開平5−225240号公報では、文書
データベースに蓄積されている構造化文書から一部分の
文書内容を抽出する文書データベース装置に関するもの
である。この発明は上述の「発明の属する分野」で定義
した構造化文書データベースシステムの一部を構成する
基本的な技術である。
【0010】特開平7−319874号公報では、デー
タベースから構造化文書を取り出して編集し、また元の
データベースに書き戻す操作に関する技術である。この
技術も構造化文書データベースシステムの一部を構成す
る基本的なものである。特開平9−6794号公報で
は、構造化文書の持つ論理構造と管理属性の条件によっ
て特定の構造化文書を検索する装置に関するものであ
り、この技術も構造化文書データベースシステムの一部
を構成する。
タベースから構造化文書を取り出して編集し、また元の
データベースに書き戻す操作に関する技術である。この
技術も構造化文書データベースシステムの一部を構成す
る基本的なものである。特開平9−6794号公報で
は、構造化文書の持つ論理構造と管理属性の条件によっ
て特定の構造化文書を検索する装置に関するものであ
り、この技術も構造化文書データベースシステムの一部
を構成する。
【0011】以上3件の構造化文書データベースシステ
ムの各一部に関する基本的な発明の他に、構造化文書に
対する検索時間の短縮に関する発明、また構造化文書の
論理構造及び文書内容の複数文書間での共有方法に関す
る発明が公開されている。特開平9−6803号公報で
は、構造化文書に対する検索式が構造化文書の論理構造
を規定する文書型定義に対して妥当(valid) な検索式で
あるかを事前にチェックし、妥当でない検索式に対して
は検索を行わないようにして検索時間の短縮を図る方式
に関する技術である。この検査式の妥当性のチェック
は、構造化文書の構成を規定する文書型定義で定義され
る各要素に対して、当該要素の子要素及び子孫要素とし
て出現可能な要素の対応表を検索実行前に作成し、当該
対応表を利用して、検索対象の要素が出現不可能である
ような検索式を検出し妥当でないと判断する方式によ
る。
ムの各一部に関する基本的な発明の他に、構造化文書に
対する検索時間の短縮に関する発明、また構造化文書の
論理構造及び文書内容の複数文書間での共有方法に関す
る発明が公開されている。特開平9−6803号公報で
は、構造化文書に対する検索式が構造化文書の論理構造
を規定する文書型定義に対して妥当(valid) な検索式で
あるかを事前にチェックし、妥当でない検索式に対して
は検索を行わないようにして検索時間の短縮を図る方式
に関する技術である。この検査式の妥当性のチェック
は、構造化文書の構成を規定する文書型定義で定義され
る各要素に対して、当該要素の子要素及び子孫要素とし
て出現可能な要素の対応表を検索実行前に作成し、当該
対応表を利用して、検索対象の要素が出現不可能である
ような検索式を検出し妥当でないと判断する方式によ
る。
【0012】特開平9−297768号公報では、特開
平9−6803号公報の検索式の妥当性チェックに用い
る対応表を利用し、入力される検索式の検索条件を満足
する文書構造を生成し得る文書型定義を検出し、文書型
定義に従う構造化文書のみを検索式の検索対象として絞
り込み、検索効率の向上を図る方式に関する技術であ
る。
平9−6803号公報の検索式の妥当性チェックに用い
る対応表を利用し、入力される検索式の検索条件を満足
する文書構造を生成し得る文書型定義を検出し、文書型
定義に従う構造化文書のみを検索式の検索対象として絞
り込み、検索効率の向上を図る方式に関する技術であ
る。
【0013】
【発明が解決しようとする課題】第一の課題は、構造化
文書の検索ではしばしば文書の論理構造を指定した検索
がなされるが、 1)文書の論理構造が複雑な場合、前記論理構造の条件
指定をユーザが検索式として誤りなく記述するのはユー
ザに負担である; 2)その文書の論理構造を誤りなく記述しようとして
も、ユーザが誤りなく文書の論理構造を把握しているか
分からない; 3)文書の論理構造は文書型定義によって規定される
が、整形式のXML 文書では文書型定義が含まれない、ま
たは文書型定義に従う必要がないので、XML 文書の文書
型定義から文書の論理構造を調べることは不可能であ
る; 4)仮に文書型定義をユーザが入手したとしても、その
文書型定義を読み取って文書の論理構造を把握すること
は困難である;などの問題点がある。
文書の検索ではしばしば文書の論理構造を指定した検索
がなされるが、 1)文書の論理構造が複雑な場合、前記論理構造の条件
指定をユーザが検索式として誤りなく記述するのはユー
ザに負担である; 2)その文書の論理構造を誤りなく記述しようとして
も、ユーザが誤りなく文書の論理構造を把握しているか
分からない; 3)文書の論理構造は文書型定義によって規定される
が、整形式のXML 文書では文書型定義が含まれない、ま
たは文書型定義に従う必要がないので、XML 文書の文書
型定義から文書の論理構造を調べることは不可能であ
る; 4)仮に文書型定義をユーザが入手したとしても、その
文書型定義を読み取って文書の論理構造を把握すること
は困難である;などの問題点がある。
【0014】よって、本発明では、従来の構造化文書デ
ータベースシステムが提供してきた検索式入力系では、
文書の論理構造を指定した検索はユーザにとって困難な
ものとなっている。ユーザが文書の論理構造の条件指定
に関して、文書型定義に従って厳密に指定しなくても、
ある程度の構造を指定するだけで論理構造に基づく構造
化文書の検索を可能とすることを目的とする。
ータベースシステムが提供してきた検索式入力系では、
文書の論理構造を指定した検索はユーザにとって困難な
ものとなっている。ユーザが文書の論理構造の条件指定
に関して、文書型定義に従って厳密に指定しなくても、
ある程度の構造を指定するだけで論理構造に基づく構造
化文書の検索を可能とすることを目的とする。
【0015】本発明の他の目的である第二の課題は、曖
昧な論理構造指定に関係して、文書内容の条件指定に関
しても曖昧でさまざまな検索条件を指定できるような系
を提供することである。例えば、ある検索キーワード文
字列が特定の文書や文書要素に含まれるかどうかの指定
だけでなく、文字列が当該文書及び文書要素の内容(す
なわち文章である)において、ある閾値を超えた出現頻
度で含まれるかどうかの指定を可能にすることも目的で
ある。
昧な論理構造指定に関係して、文書内容の条件指定に関
しても曖昧でさまざまな検索条件を指定できるような系
を提供することである。例えば、ある検索キーワード文
字列が特定の文書や文書要素に含まれるかどうかの指定
だけでなく、文字列が当該文書及び文書要素の内容(す
なわち文章である)において、ある閾値を超えた出現頻
度で含まれるかどうかの指定を可能にすることも目的で
ある。
【0016】現在の文書検索技術では、システムが文書
の意味を解釈して、ある意味に適合する文書のみを取り
出すことは極めて困難である。しかし、例えばキーワー
ド「データベース」がある文書中にある閾値以上の出現
頻度で含まれれば、文書は「データベース」に関する説
明文であるという仮定をおき、その意味で文書の意味の
領域に一歩踏み入れた文書検索を実現させる可能性を持
たせることができる。単純に「データベース」というキ
ーワードが含まれるかどうかだけの条件指定から一段進
み、「データベース」に関する説明文を検索するという
ユーザの意図を極力組み入れる検索方法を提供する。ま
た、文書内容の検索を高速に行うことも本発明の目的で
ある。
の意味を解釈して、ある意味に適合する文書のみを取り
出すことは極めて困難である。しかし、例えばキーワー
ド「データベース」がある文書中にある閾値以上の出現
頻度で含まれれば、文書は「データベース」に関する説
明文であるという仮定をおき、その意味で文書の意味の
領域に一歩踏み入れた文書検索を実現させる可能性を持
たせることができる。単純に「データベース」というキ
ーワードが含まれるかどうかだけの条件指定から一段進
み、「データベース」に関する説明文を検索するという
ユーザの意図を極力組み入れる検索方法を提供する。ま
た、文書内容の検索を高速に行うことも本発明の目的で
ある。
【0017】さらに関連する課題として、一般に全文検
索エンジンによる文書に対するインデックス作成時間
は、ある一定の処理時間を要する。この処理の最中に全
文検索エンジンが停止したりしてインデックス作成が途
中になり、インデックスと文書との関係の一貫性が保持
できなくなったり、また何らかの障害で作成したインデ
ックスが壊れた場合はもう一度作成し直さなければなら
ないなどの問題がある。この問題の解決も本発明の第三
の課題、すなわち目的である。
索エンジンによる文書に対するインデックス作成時間
は、ある一定の処理時間を要する。この処理の最中に全
文検索エンジンが停止したりしてインデックス作成が途
中になり、インデックスと文書との関係の一貫性が保持
できなくなったり、また何らかの障害で作成したインデ
ックスが壊れた場合はもう一度作成し直さなければなら
ないなどの問題がある。この問題の解決も本発明の第三
の課題、すなわち目的である。
【0018】本発明の第四の課題は、第一の課題に関す
る曖昧な論理構造の指定による検索は、厳密に構造を指
定する方法より冗長なオブジェクト間の経路探索(オブ
ジェクトナビゲーション)処理が発生することが予想さ
れる。曖昧な構造指定による検索によっても、極力オブ
ジェクトナビゲーション処理の回数を減らし、検索時間
を短縮することである。
る曖昧な論理構造の指定による検索は、厳密に構造を指
定する方法より冗長なオブジェクト間の経路探索(オブ
ジェクトナビゲーション)処理が発生することが予想さ
れる。曖昧な構造指定による検索によっても、極力オブ
ジェクトナビゲーション処理の回数を減らし、検索時間
を短縮することである。
【0019】
【課題を解決するための手段】本発明によれば、構造化
文書の文書型定義部分をオブジェクトとして格納する文
書型定義格納部と、前記構造化文書の文書インスタンス
部分をオブジェクトとして格納する文書インスタンス格
納部と、前記文書インスタンス(または単に文書)に含
まれる各文書要素(または単に要素)を、そのつながり
関係を保持したままオブジェクトとして格納する文書要
素格納部とを具備したオブジェクト指向データベース
と、前記構造化文書を前記データベースに対して格納制
御する構造化文書入力部と、を含むことを特徴とする構
造化文書データベースシステムが得られる。
文書の文書型定義部分をオブジェクトとして格納する文
書型定義格納部と、前記構造化文書の文書インスタンス
部分をオブジェクトとして格納する文書インスタンス格
納部と、前記文書インスタンス(または単に文書)に含
まれる各文書要素(または単に要素)を、そのつながり
関係を保持したままオブジェクトとして格納する文書要
素格納部とを具備したオブジェクト指向データベース
と、前記構造化文書を前記データベースに対して格納制
御する構造化文書入力部と、を含むことを特徴とする構
造化文書データベースシステムが得られる。
【0020】更に、前記データベースに格納された構造
化文書に対する論理構造及び文書内容の追加・変更・削
除の各操作、また前記論理構造及び文書内容の複数文書
間での共有化を可能にする構造化文書操作部を含み、ま
た、前記データベースに格納された構造化文書に対する
検索を目的とした文書検索式を入力として受け取る文書
検索式入力部と、前記文書検索式を解析し、前記データ
ベースに格納される文書及び文書要素の検索を実行する
文書検索部に対する検索プログラムを組み立て、そして
実行する文書検索解析部とを含むことを特徴とする。
化文書に対する論理構造及び文書内容の追加・変更・削
除の各操作、また前記論理構造及び文書内容の複数文書
間での共有化を可能にする構造化文書操作部を含み、ま
た、前記データベースに格納された構造化文書に対する
検索を目的とした文書検索式を入力として受け取る文書
検索式入力部と、前記文書検索式を解析し、前記データ
ベースに格納される文書及び文書要素の検索を実行する
文書検索部に対する検索プログラムを組み立て、そして
実行する文書検索解析部とを含むことを特徴とする。
【0021】さらにはまた、前記データベースに格納さ
れた構造化文書に対する検索を実行し、目的の文書及び
文書要素をオブジェクト指向データベースから取り出す
文書検索実行部を含むことを特徴とし、また前記文書検
索式入力部は、Stanford大学のLorel などに代表される
General Path Expression (オブジェクト参照関係のパ
スやラベルにワイルドカードを含めたり、正規表現を用
いたりする記述)を含む拡張OQL(Object Query Languag
e)を用いて、構造化文書の検索における論理構造や文書
内容の条件に曖昧な指定を可能とする文書検索式が入力
自在であることを特徴とする。
れた構造化文書に対する検索を実行し、目的の文書及び
文書要素をオブジェクト指向データベースから取り出す
文書検索実行部を含むことを特徴とし、また前記文書検
索式入力部は、Stanford大学のLorel などに代表される
General Path Expression (オブジェクト参照関係のパ
スやラベルにワイルドカードを含めたり、正規表現を用
いたりする記述)を含む拡張OQL(Object Query Languag
e)を用いて、構造化文書の検索における論理構造や文書
内容の条件に曖昧な指定を可能とする文書検索式が入力
自在であることを特徴とする。
【0022】更に、前記文書検索解析部が組み立てた検
索プログラムの、前記データベースにおけるオブジェク
トナビゲーションの回数を最小に押さえてその処理時間
を短縮させることを目的とした最適なナビゲーション処
理手順の算出及び検索の目標オブジェクトに直接処理を
移動できるオブジェクト参照関係の作成を行う文書検索
最適化部を含むことを特徴とする。
索プログラムの、前記データベースにおけるオブジェク
トナビゲーションの回数を最小に押さえてその処理時間
を短縮させることを目的とした最適なナビゲーション処
理手順の算出及び検索の目標オブジェクトに直接処理を
移動できるオブジェクト参照関係の作成を行う文書検索
最適化部を含むことを特徴とする。
【0023】また、前記文書検索式入力部は、前記曖昧
な条件指定を可能とする検索式で、文書内容の条件指定
で単にある文字列が含まれることを条件とする他に、前
記文字列が当該文書内容にある閾値を超えた頻度で含ま
れることを条件とするなどの曖昧な指定を可能とするよ
う構成されており、前記文書検索部に含まれる前記当該
文書内容の文字列検索を高速に行う全文検索エンジン部
と、前記全文検索エンジン部が文書及び文書要素に対し
てあらかじめ作成する文書インデックスを格納する文書
インデックス格納部とを含むことを特徴とし、更に前記
文書検索実行部を含む文書検索部が出力する文書及び文
書要素の論理構造も含めた文書内容の表示を行う検索文
書表示部を含むことを特徴とする。
な条件指定を可能とする検索式で、文書内容の条件指定
で単にある文字列が含まれることを条件とする他に、前
記文字列が当該文書内容にある閾値を超えた頻度で含ま
れることを条件とするなどの曖昧な指定を可能とするよ
う構成されており、前記文書検索部に含まれる前記当該
文書内容の文字列検索を高速に行う全文検索エンジン部
と、前記全文検索エンジン部が文書及び文書要素に対し
てあらかじめ作成する文書インデックスを格納する文書
インデックス格納部とを含むことを特徴とし、更に前記
文書検索実行部を含む文書検索部が出力する文書及び文
書要素の論理構造も含めた文書内容の表示を行う検索文
書表示部を含むことを特徴とする。
【0024】
【発明の実施の形態】以下に本発明の実施の形態につき
図面を参照しつつ説明する。前述した本発明の第一の課
題に対する解決手段としては、まず検索式の論理構造条
件に対する曖昧な記述を可能とする体系を用意すること
である。図1は本発明の実施の形態の概略ブロック図で
ある。
図面を参照しつつ説明する。前述した本発明の第一の課
題に対する解決手段としては、まず検索式の論理構造条
件に対する曖昧な記述を可能とする体系を用意すること
である。図1は本発明の実施の形態の概略ブロック図で
ある。
【0025】本発明では、Serge Abiteboul, Dallan Qu
ass, Jason McHugh, Jennifer Widom, Janet L. Wiene
r, “The Lorel Query Language for Semistructured D
ata”, Journal of Digital Libraries Manuscript N
r., 1997. で説明されているLorel と呼ばれる拡張OQL
で用いられる、General Path Expression (オブジェ
クト参照関係のパスやオブジェクトのメンバを表すラベ
ルにワイルドカードを含めたり、正規表現を用いたりす
る記述)を検索式に含めることのできる記述体系を文書
検索式入力部3で用意する。
ass, Jason McHugh, Jennifer Widom, Janet L. Wiene
r, “The Lorel Query Language for Semistructured D
ata”, Journal of Digital Libraries Manuscript N
r., 1997. で説明されているLorel と呼ばれる拡張OQL
で用いられる、General Path Expression (オブジェ
クト参照関係のパスやオブジェクトのメンバを表すラベ
ルにワイルドカードを含めたり、正規表現を用いたりす
る記述)を検索式に含めることのできる記述体系を文書
検索式入力部3で用意する。
【0026】一方、オブジェクト指向データベース2に
対して実際に検索を実行する文書検索部5はデータベー
スクラスのメソッドあるいは一般の関数として実装さ
れ、モジュールとして提供される。モジュールはオブジ
ェクト指向データベース2に対する様々な検索機能を実
現し、外部の環境にAPI(Application Program Interfac
e)として公開する。
対して実際に検索を実行する文書検索部5はデータベー
スクラスのメソッドあるいは一般の関数として実装さ
れ、モジュールとして提供される。モジュールはオブジ
ェクト指向データベース2に対する様々な検索機能を実
現し、外部の環境にAPI(Application Program Interfac
e)として公開する。
【0027】文書検索式入力部3で用意する拡張OQL の
記述体系と、文書検索部5が用意する検索モジュールを
呼び出すためのAPI とでは、記述体系が異なる。一般に
は一つの拡張OQL による検索式を実行するためには、複
数の検索モジュールを手続き的に呼び出す必要がある。
この拡張OQL による検索式に基づいて実行すべき検索モ
ジュールの順序を組み立てる部分が文書検索式解析部4
である。そして実際の検索モジュールの実行を行うのが
文書検索部5である。
記述体系と、文書検索部5が用意する検索モジュールを
呼び出すためのAPI とでは、記述体系が異なる。一般に
は一つの拡張OQL による検索式を実行するためには、複
数の検索モジュールを手続き的に呼び出す必要がある。
この拡張OQL による検索式に基づいて実行すべき検索モ
ジュールの順序を組み立てる部分が文書検索式解析部4
である。そして実際の検索モジュールの実行を行うのが
文書検索部5である。
【0028】検索結果として返される構造化文書を表示
する手段として、検索文書表示部6を用意する。この検
索文書表示部6は通常のテキスト表示ブラウザ/エディ
タ、HTML文書を表示するWWW ブラウザ、SGML文書やXML
文書を表示する専用ブラウザなど、本発明ではどれを選
んでも良い。
する手段として、検索文書表示部6を用意する。この検
索文書表示部6は通常のテキスト表示ブラウザ/エディ
タ、HTML文書を表示するWWW ブラウザ、SGML文書やXML
文書を表示する専用ブラウザなど、本発明ではどれを選
んでも良い。
【0029】以上の文書検索式入力部3、文書検索式解
析部4、文書検索部5、検索文書表示部6の連携手順の
フローチャートを図2に示す。検索式が入力されるステ
ップ11は、本システムのユーザが文書検索入力部3に
検索式を入力するステップである。システムは文書検索
式解析部4で検索式の文法チェック(ステップ12)を
行い、誤りがあればユーザにその誤り個所を提示し、ユ
ーザは検索式を修正し(ステップ13)、再度検索式を
入力する(ステップ11)。ステップ12は一般にパー
ズ(parse) と呼ばれる処理である。
析部4、文書検索部5、検索文書表示部6の連携手順の
フローチャートを図2に示す。検索式が入力されるステ
ップ11は、本システムのユーザが文書検索入力部3に
検索式を入力するステップである。システムは文書検索
式解析部4で検索式の文法チェック(ステップ12)を
行い、誤りがあればユーザにその誤り個所を提示し、ユ
ーザは検索式を修正し(ステップ13)、再度検索式を
入力する(ステップ11)。ステップ12は一般にパー
ズ(parse) と呼ばれる処理である。
【0030】文書検索式解析部4のパーズ処理により検
索文が正しいと判断されれば、その検索文の実行に相当
する文書検索部5の各検索モジュールを実行すべく、検
索モジュールの実行順序を決定する(ステップ14)。
このステップ14は一般に最適化と呼ばれる処理であ
る。また検索モジュールとは、文書検索部5を構成する
ものであり、オブジェクト指向データベース2に対する
検索処理を行う。
索文が正しいと判断されれば、その検索文の実行に相当
する文書検索部5の各検索モジュールを実行すべく、検
索モジュールの実行順序を決定する(ステップ14)。
このステップ14は一般に最適化と呼ばれる処理であ
る。また検索モジュールとは、文書検索部5を構成する
ものであり、オブジェクト指向データベース2に対する
検索処理を行う。
【0031】各検索モジュールはステップ14の最適化
によってならべられた順序に従って、手続き的に実行さ
れる(ステップ15)。そしてオブジェクト指向データ
ベース2から検索の結果として構造化文書が取出される
(ステップ16)。文書検索部5は前記結果の構造化文
書を検索文書表示部6に渡し、検索表示部6は構造化文
書を表示し(ステップ17)、ユーザは検索結果内容を
閲覧することができる。
によってならべられた順序に従って、手続き的に実行さ
れる(ステップ15)。そしてオブジェクト指向データ
ベース2から検索の結果として構造化文書が取出される
(ステップ16)。文書検索部5は前記結果の構造化文
書を検索文書表示部6に渡し、検索表示部6は構造化文
書を表示し(ステップ17)、ユーザは検索結果内容を
閲覧することができる。
【0032】曖昧な論理構造指定を可能にする検索式の
記述方法について説明する。基本的には、OQL の文法体
系に、Lorel などで用いられるGeneral Path Expressio
n の使用を許した検索式の記述となる。またこの検索式
の記述方法に関して、本発明でもまた独自の拡張を行っ
ている。本発明の拡張も含めて、その記述方法について
説明する。
記述方法について説明する。基本的には、OQL の文法体
系に、Lorel などで用いられるGeneral Path Expressio
n の使用を許した検索式の記述となる。またこの検索式
の記述方法に関して、本発明でもまた独自の拡張を行っ
ている。本発明の拡張も含めて、その記述方法について
説明する。
【0033】構造化文書の論理構造の指定は、図4の文
書インスタンスを例にとると、「カルテ」の一番目の
「記録」の一番目の「病名」の一番目の「原因」という
ように厳密に指定する必要がある。しかし、前述の第一
の課題で述べた通り、文書構造が複雑になればなるほど
その論理構造の指定は難しく誤りも多くなりまた不便で
ある。そこでLorel などではワイルドカードを用いて厳
密な論理構造に指定に曖昧性を持たせた記述方式を提案
している。
書インスタンスを例にとると、「カルテ」の一番目の
「記録」の一番目の「病名」の一番目の「原因」という
ように厳密に指定する必要がある。しかし、前述の第一
の課題で述べた通り、文書構造が複雑になればなるほど
その論理構造の指定は難しく誤りも多くなりまた不便で
ある。そこでLorel などではワイルドカードを用いて厳
密な論理構造に指定に曖昧性を持たせた記述方式を提案
している。
【0034】そのワイルドカードは木構造上の(Lorelで
はグラフ構造上の) 任意のオブジェクトパスにマッチす
る‘#’、各要素の任意の属性値または内容(Lorel で
はノード上のラベルの値)にマッチする‘%’である。
図4の例で、「カルテ.#.病名.%」と指定すれば、
カルテから辿ることのできる病名の中の任意の属性値ま
たは中身を指定することになり、“盲腸”と“胃潰瘍”
がこれに相当する。
はグラフ構造上の) 任意のオブジェクトパスにマッチす
る‘#’、各要素の任意の属性値または内容(Lorel で
はノード上のラベルの値)にマッチする‘%’である。
図4の例で、「カルテ.#.病名.%」と指定すれば、
カルテから辿ることのできる病名の中の任意の属性値ま
たは中身を指定することになり、“盲腸”と“胃潰瘍”
がこれに相当する。
【0035】ここで特徴的なことは、ワイルドカードの
指定によりカルテと病名の間の「記録」の指定を省略し
たことである。カルテの中のどこかに病名が存在するこ
とが既に分かっているユーザにとっては、論理構造指定
の簡略化を可能にしたことになる。また厳密な論理構造
指定に伴う誤りの機会を減らしたことにもなる。またカ
ルテの中に病名が存在すること自体は分かっていても、
その場所を厳密に指定することができないユーザにとっ
ては、その論理構造指定の難しさを緩和したことにな
る。
指定によりカルテと病名の間の「記録」の指定を省略し
たことである。カルテの中のどこかに病名が存在するこ
とが既に分かっているユーザにとっては、論理構造指定
の簡略化を可能にしたことになる。また厳密な論理構造
指定に伴う誤りの機会を減らしたことにもなる。またカ
ルテの中に病名が存在すること自体は分かっていても、
その場所を厳密に指定することができないユーザにとっ
ては、その論理構造指定の難しさを緩和したことにな
る。
【0036】さらに、図5に示すような図の文書型定義
でない別の文書型定義に従った文書インスタンスがあっ
たときも、ワイルドカードを用いた論理構造指定は有効
である。カルテと病名の間の論理構造である「記録.経
過記録.疾患履歴」はワイルドカード#によって吸収さ
れ、結果として指定される値は図4の文書インスタンス
の場合と同様に“盲腸”と“胃潰瘍”となる。場合によ
って文書型定義の違いを吸収し、論理構造の指定方法を
変えずに同じように適用できる文書論理構造指定方法と
なっている。
でない別の文書型定義に従った文書インスタンスがあっ
たときも、ワイルドカードを用いた論理構造指定は有効
である。カルテと病名の間の論理構造である「記録.経
過記録.疾患履歴」はワイルドカード#によって吸収さ
れ、結果として指定される値は図4の文書インスタンス
の場合と同様に“盲腸”と“胃潰瘍”となる。場合によ
って文書型定義の違いを吸収し、論理構造の指定方法を
変えずに同じように適用できる文書論理構造指定方法と
なっている。
【0037】ワイルドカード%の効用について述べる。
一般に要素は0以上の属性を持ち、それぞれに値が設定
される。また要素はその要素名を持つタグによって囲ん
だ文書内容(中身)も含んでいる。もし、図4に示した
ように要素「病名1」に含まれる文字列“盲腸”が、例
えば属性「主要病名」の値であることが分かっている場
合は、論理構造指定において、「病名.主要病名」と指
定すれば目的の文字列“盲腸”の格納位置を指定でき
る。
一般に要素は0以上の属性を持ち、それぞれに値が設定
される。また要素はその要素名を持つタグによって囲ん
だ文書内容(中身)も含んでいる。もし、図4に示した
ように要素「病名1」に含まれる文字列“盲腸”が、例
えば属性「主要病名」の値であることが分かっている場
合は、論理構造指定において、「病名.主要病名」と指
定すれば目的の文字列“盲腸”の格納位置を指定でき
る。
【0038】しかし、主要病名に含まれいるかどうか分
からない、また主要病名ではなく、例えば属性「疑い病
名」に含まれているかどうか判断がつかない場合は、ワ
イルドカード%を用いて「病名、%病名」と属性名の部
分一致を用いたり、またはすべての属性値または内容
(中身)とマッチする「病名.%」と指定したりして、
目的の“盲腸”の格納位置を指定できる。
からない、また主要病名ではなく、例えば属性「疑い病
名」に含まれているかどうか判断がつかない場合は、ワ
イルドカード%を用いて「病名、%病名」と属性名の部
分一致を用いたり、またはすべての属性値または内容
(中身)とマッチする「病名.%」と指定したりして、
目的の“盲腸”の格納位置を指定できる。
【0039】実際の検索式の記述方法について説明す
る。検索式はOQL やSQL と同様に基本的にselect、fro
m、where の各句で構成される。図4の文書インスタン
スを例に説明する。病名“盲腸”の原因を調べなさい」
という検索要求を記述する検索式は、例えば図6のよう
に記述することが可能である。from句から説明すると、
キーワードrootは本発明で導入するキーワードである
が、対象とする構造化文書のルート要素を示す。図4の
例では、要素「カルテ」となる。「root.#.病名D」
で、カルテから辿ることのできる要素「病名」の集合を
Dと置いている。さらに「D.#.原因」で、Dからた
どることのできる「原因」の集合をCとおいている。
る。検索式はOQL やSQL と同様に基本的にselect、fro
m、where の各句で構成される。図4の文書インスタン
スを例に説明する。病名“盲腸”の原因を調べなさい」
という検索要求を記述する検索式は、例えば図6のよう
に記述することが可能である。from句から説明すると、
キーワードrootは本発明で導入するキーワードである
が、対象とする構造化文書のルート要素を示す。図4の
例では、要素「カルテ」となる。「root.#.病名D」
で、カルテから辿ることのできる要素「病名」の集合を
Dと置いている。さらに「D.#.原因」で、Dからた
どることのできる「原因」の集合をCとおいている。
【0040】where 句では、ある検索条件を示してお
り、要素Dの任意の属性値または内容(中身)に“盲
腸”という文字列が含まれているかどうかをチェック
し、その条件を満たす要素Dの集合を限定している。li
keは要素Dのオブジェクトメンバから呼び出すメソッド
である。ワイルドカード%によって要素Dのオブジェク
トの何かしらのメンバとマッチし、そのメンバからメソ
ッドlikeが呼び出されている。今回の例では、要素Dの
中身はオブジェクトメンバcontentsに格納しているとし
て、オブジェクトcontentsの中身の文書に対して全文検
索による文字列検索を行うメソッドlikeとして用いてい
る。よって、要素の中身に“盲腸”という文字列を含ん
でいる要素集合Dを特定している。
り、要素Dの任意の属性値または内容(中身)に“盲
腸”という文字列が含まれているかどうかをチェック
し、その条件を満たす要素Dの集合を限定している。li
keは要素Dのオブジェクトメンバから呼び出すメソッド
である。ワイルドカード%によって要素Dのオブジェク
トの何かしらのメンバとマッチし、そのメンバからメソ
ッドlikeが呼び出されている。今回の例では、要素Dの
中身はオブジェクトメンバcontentsに格納しているとし
て、オブジェクトcontentsの中身の文書に対して全文検
索による文字列検索を行うメソッドlikeとして用いてい
る。よって、要素の中身に“盲腸”という文字列を含ん
でいる要素集合Dを特定している。
【0041】select句では、検索結果として取出す要素
を指定している。where 句で制限された要素Dから辿る
ことのできる要素「原因」を結果として取出すことを指
定している。この検索に関して曖昧指定を許さない厳密
な指定を行うとすれば図7のような検索式となる。図7
の検索式と比較して図6の検索式における曖昧性指定個
所をまとめると、以下が挙げられる。 1)ルート要素が何かを指定していない; 2)ルート要素から病名を辿り、さらに病名から原因を
たどることは指定したが、その途中に関する論理構造に
関しては指定していない; 3)病名の内容(中身)がオブジェクトメンバとしてど
こに格納されているかを指定せず、ただメソッドlikeを
呼び出すことのできるオブジェクトメンバとしてのみ指
定している。
を指定している。where 句で制限された要素Dから辿る
ことのできる要素「原因」を結果として取出すことを指
定している。この検索に関して曖昧指定を許さない厳密
な指定を行うとすれば図7のような検索式となる。図7
の検索式と比較して図6の検索式における曖昧性指定個
所をまとめると、以下が挙げられる。 1)ルート要素が何かを指定していない; 2)ルート要素から病名を辿り、さらに病名から原因を
たどることは指定したが、その途中に関する論理構造に
関しては指定していない; 3)病名の内容(中身)がオブジェクトメンバとしてど
こに格納されているかを指定せず、ただメソッドlikeを
呼び出すことのできるオブジェクトメンバとしてのみ指
定している。
【0042】ワイルドカード#を用いる際の問題点につ
いて述べる。図8の検索式を図4の文書インスタンスに
適用する例でその問題点を示す。図8の検索式では、fr
om句の「root.#.病名」で指定する要素「病名」を、
where 句の条件指定で要素「病名1」を特定している。
しかし、目的として取出す要素は、「root.#.原因」
と指定されているため、要素「原因1」と「原因2」と
が取出されてしまう。すなわち、最初の「病名1」を特
定して「病名2」を排除する条件指定をしても、「roo
t.#.原因」のワイルドカード#によって要素「原
因」までのすべての経路がマッチしてしまうために、こ
のような結果となる。
いて述べる。図8の検索式を図4の文書インスタンスに
適用する例でその問題点を示す。図8の検索式では、fr
om句の「root.#.病名」で指定する要素「病名」を、
where 句の条件指定で要素「病名1」を特定している。
しかし、目的として取出す要素は、「root.#.原因」
と指定されているため、要素「原因1」と「原因2」と
が取出されてしまう。すなわち、最初の「病名1」を特
定して「病名2」を排除する条件指定をしても、「roo
t.#.原因」のワイルドカード#によって要素「原
因」までのすべての経路がマッチしてしまうために、こ
のような結果となる。
【0043】この問題を解決すべく、本発明ではワイル
ドカード#の経路に関して制限を加える方法とその記述
方法を検索式に導入する。この記述方法に関しては、Lo
relなどで述べている経路指定子‘@’の後にその経路
を表す変数を与え、where 句で前記変数を用いて経路に
関して条件を加える方法を採用する。本発明では、この
経路指定子‘@’を用いてワイルドカード#の経路を限
定する5 種類の方法について述べる。
ドカード#の経路に関して制限を加える方法とその記述
方法を検索式に導入する。この記述方法に関しては、Lo
relなどで述べている経路指定子‘@’の後にその経路
を表す変数を与え、where 句で前記変数を用いて経路に
関して条件を加える方法を採用する。本発明では、この
経路指定子‘@’を用いてワイルドカード#の経路を限
定する5 種類の方法について述べる。
【0044】1種類目の限定方法の例を図9に示し、そ
の限定の手順のフローチャートを図10に示す。図9で
は、from句で「root.#@p.病名」とおき、rootから
病名まで辿ることのできるすべての経路#を変数pで置
き換えている。そしてwhere句で、「p.case=1」と
指定している。この記法に関しては本発明独自のOQLに
対する拡張である。ワイルドカード#の経路を表す変数
pもオブジェクトとして捉えており、そのメンバ変数ca
seを設定して、指定方法を1としている。本発明ではこ
の表記方法が重要なのではなく、どのような表記方法を
採用するかは、OQL やSQL を拡張するユーザに任され
る。本発明の範囲は、以下で述べるワイルドカード#の
限定方法が5種類存在することと、その指定ごとの検索
時における処理方法である。
の限定の手順のフローチャートを図10に示す。図9で
は、from句で「root.#@p.病名」とおき、rootから
病名まで辿ることのできるすべての経路#を変数pで置
き換えている。そしてwhere句で、「p.case=1」と
指定している。この記法に関しては本発明独自のOQLに
対する拡張である。ワイルドカード#の経路を表す変数
pもオブジェクトとして捉えており、そのメンバ変数ca
seを設定して、指定方法を1としている。本発明ではこ
の表記方法が重要なのではなく、どのような表記方法を
採用するかは、OQL やSQL を拡張するユーザに任され
る。本発明の範囲は、以下で述べるワイルドカード#の
限定方法が5種類存在することと、その指定ごとの検索
時における処理方法である。
【0045】図10のフローチャート内での用語、起点
要素、目標要素とは、ルート要素から辿ることのできる
要素A,Bに関して「A.#.B」と指定されたときの
Aが起点要素、Bが目標要素ということである。また検
索木とは、データベース内に実際に格納されている木構
造を持つ文書インスタンスをシステムのメモリ上にロー
ドして、検索時のみに利用される一時的なデータ格納構
造である。よって、検索木上の様々な追加・削除・変更
操作は、データベース内のデータの追加・削除・変更と
は異なる。検索木上のデータ操作をデータベースに反映
させるためには、別の手順、例えばデータベースを書き
込み専用としてオープンし、トランザクションのコミッ
ト操作によってメモリ上のデータをデータベースに反映
させる必要がある。しかし、本手順では、データベース
のオープンは検索を目的とした読み込み専用として利用
するので、検索木上でのデータ変更は、データベースに
は反映されない。
要素、目標要素とは、ルート要素から辿ることのできる
要素A,Bに関して「A.#.B」と指定されたときの
Aが起点要素、Bが目標要素ということである。また検
索木とは、データベース内に実際に格納されている木構
造を持つ文書インスタンスをシステムのメモリ上にロー
ドして、検索時のみに利用される一時的なデータ格納構
造である。よって、検索木上の様々な追加・削除・変更
操作は、データベース内のデータの追加・削除・変更と
は異なる。検索木上のデータ操作をデータベースに反映
させるためには、別の手順、例えばデータベースを書き
込み専用としてオープンし、トランザクションのコミッ
ト操作によってメモリ上のデータをデータベースに反映
させる必要がある。しかし、本手順では、データベース
のオープンは検索を目的とした読み込み専用として利用
するので、検索木上でのデータ変更は、データベースに
は反映されない。
【0046】ステップ21で、ルート要素から辿ること
のできるすべての起点要素を探索する。そうして見つか
ったすべての起点要素に対して、ステップ22以下ステ
ップ22´までのループ処理を行う。ステップ23で
は、「起点要素.#.目標要素」を評価する。ステップ
24では、評価されたすべての目標要素に対してステッ
プ24以下ステップ24´までのループ処理を行う。ス
テップ25では、目標要素に対する条件指定を行ってい
るwhere 句を評価する。そして、条件に満たなかった目
標要素のみに、ステップ26で除外フラグというあるフ
ラグを立てる。そしてすべての目標要素を評価し終えた
ら、ステップ27で、除外フラグが立っている目標要素
をすべて検索木から除外する。
のできるすべての起点要素を探索する。そうして見つか
ったすべての起点要素に対して、ステップ22以下ステ
ップ22´までのループ処理を行う。ステップ23で
は、「起点要素.#.目標要素」を評価する。ステップ
24では、評価されたすべての目標要素に対してステッ
プ24以下ステップ24´までのループ処理を行う。ス
テップ25では、目標要素に対する条件指定を行ってい
るwhere 句を評価する。そして、条件に満たなかった目
標要素のみに、ステップ26で除外フラグというあるフ
ラグを立てる。そしてすべての目標要素を評価し終えた
ら、ステップ27で、除外フラグが立っている目標要素
をすべて検索木から除外する。
【0047】この一連の操作により、図9の検索式「ro
ot.#@p.病名」のルートから辿ることのできる要素
「病名」のうち、図4の要素「病名2」が除外されるこ
ととなる。検索木における要素の探索では、ルート要素
以外はすべて親要素が存在しなければ探索されない。よ
って「病名2」以下の要素「患者b」と「原因2」も、
親要素「病名2」を失うことによって事実上検索木から
除外されることとなる。以上の操作により、図9の検索
式の実行結果は、図4の要素「原因1」が返されること
となる。
ot.#@p.病名」のルートから辿ることのできる要素
「病名」のうち、図4の要素「病名2」が除外されるこ
ととなる。検索木における要素の探索では、ルート要素
以外はすべて親要素が存在しなければ探索されない。よ
って「病名2」以下の要素「患者b」と「原因2」も、
親要素「病名2」を失うことによって事実上検索木から
除外されることとなる。以上の操作により、図9の検索
式の実行結果は、図4の要素「原因1」が返されること
となる。
【0048】2種類目の限定方法とその手順について説
明する。その前にまず、前述の限定法法が必要な場合を
示す。図4の文書インスタンスに対して、図11の検索
式を適用する。図11の検索式の意図は、「“盲腸”で
ある患者以外の患者の情報を取得せよ」であるとする。
図11の検索式では、from句の「root.#.病名」で指
定する要素「病名」をwhere 句の条件指定で、“盲腸”
という文字列を含まない要素を特定するメンバ関数not
likeによって、要素「病名2」を特定している。目的と
して取出す要素は、「root.#.患者」と指定されてい
る。
明する。その前にまず、前述の限定法法が必要な場合を
示す。図4の文書インスタンスに対して、図11の検索
式を適用する。図11の検索式の意図は、「“盲腸”で
ある患者以外の患者の情報を取得せよ」であるとする。
図11の検索式では、from句の「root.#.病名」で指
定する要素「病名」をwhere 句の条件指定で、“盲腸”
という文字列を含まない要素を特定するメンバ関数not
likeによって、要素「病名2」を特定している。目的と
して取出す要素は、「root.#.患者」と指定されてい
る。
【0049】検索の結果は、病名に関する条件指定とは
関係なく、「患者1」、「患者2」、「患者3」が取出
される。すなわち、最初の「病名2」を特定して「病名
1」を排除する条件指定をしても、「root.#.患者」
のワイルドカード#によって要素「患者」までのすべて
の経路がマッチしてしまうために、このような結果が起
ってしまうのである。
関係なく、「患者1」、「患者2」、「患者3」が取出
される。すなわち、最初の「病名2」を特定して「病名
1」を排除する条件指定をしても、「root.#.患者」
のワイルドカード#によって要素「患者」までのすべて
の経路がマッチしてしまうために、このような結果が起
ってしまうのである。
【0050】この問題を解決すべく、2種類目の限定方
法を導入する。この2種類目の限定方法の例を図12に
示し、その限定の手順のフローチャートを図13に示
す。ステップ31からステップ35までは、限定方法1
のステップ21からステップ25まで同様である。異な
るステップは、条件を満たさない当該目標要素に対して
は、ステップ36aでその目標要素から当該起点要素ま
でのすべての要素に除外フラグを付けること、条件を満
たす当該目標要素に対しては、ステップ36bで逆にキ
ープフラグを付けることである。そして、ステップ37
で、除該フラグしか付いていない要素をすべて検索木か
ら除外する。除外フラグとキープフラグの2つが付いて
いる要素に関しては除外しない。
法を導入する。この2種類目の限定方法の例を図12に
示し、その限定の手順のフローチャートを図13に示
す。ステップ31からステップ35までは、限定方法1
のステップ21からステップ25まで同様である。異な
るステップは、条件を満たさない当該目標要素に対して
は、ステップ36aでその目標要素から当該起点要素ま
でのすべての要素に除外フラグを付けること、条件を満
たす当該目標要素に対しては、ステップ36bで逆にキ
ープフラグを付けることである。そして、ステップ37
で、除該フラグしか付いていない要素をすべて検索木か
ら除外する。除外フラグとキープフラグの2つが付いて
いる要素に関しては除外しない。
【0051】この一連の操作により、図12の検索式
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図4の要素「病名1」のみが除
外され、かつ「病名1」から起点要素「カルテ」におけ
るすべての要素、すなわち図4の場合は要素「記録1」
が除外されることになる。さらに「記録1」の除外に伴
い、以下の要素「患者1」も親要素を失うことによって
事実上検索木から除外される。以上の操作により図12
の検索式の実行結果は、図4の要素「患者2」と「患者
3」とが返されることとなる。すなわちこれらの患者
は、「“盲腸”である患者以外の患者」である。
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図4の要素「病名1」のみが除
外され、かつ「病名1」から起点要素「カルテ」におけ
るすべての要素、すなわち図4の場合は要素「記録1」
が除外されることになる。さらに「記録1」の除外に伴
い、以下の要素「患者1」も親要素を失うことによって
事実上検索木から除外される。以上の操作により図12
の検索式の実行結果は、図4の要素「患者2」と「患者
3」とが返されることとなる。すなわちこれらの患者
は、「“盲腸”である患者以外の患者」である。
【0052】3種類目の限定方法とその手順について説
明する。その前にまず、この3種類目の限定方法が必要
な場合を示す。図4の文書インスタンスに対して、図1
4の検索式を適用する。図14の検索式の意図は、
「“盲腸”である患者の患者の情報を取得せよ」である
とする。図14の検索式では、from句の「root.#.病
名」で指定する要素「病名」をwhere 句の条件指定で、
“盲腸”という文字列を含む要素「病名1」を特定して
いる。目的として取出す要素は、「root.#.患者」と
指定されている。
明する。その前にまず、この3種類目の限定方法が必要
な場合を示す。図4の文書インスタンスに対して、図1
4の検索式を適用する。図14の検索式の意図は、
「“盲腸”である患者の患者の情報を取得せよ」である
とする。図14の検索式では、from句の「root.#.病
名」で指定する要素「病名」をwhere 句の条件指定で、
“盲腸”という文字列を含む要素「病名1」を特定して
いる。目的として取出す要素は、「root.#.患者」と
指定されている。
【0053】検索の結果は、病名に関する条件指定とは
関係なく、「患者1」、「患者2」、「患者3」が取出
される。すなわち、2種類目の限定方法の問題点で述べ
たときと同様に、最初の「病名1」を特定して「病名
2」を排除する条件指定をしても、「root.#.患者」
のワイルドカード#によって要素「患者」までのすべて
の経路がマッチしてしまうために、このような結果が起
こってしまうのである。
関係なく、「患者1」、「患者2」、「患者3」が取出
される。すなわち、2種類目の限定方法の問題点で述べ
たときと同様に、最初の「病名1」を特定して「病名
2」を排除する条件指定をしても、「root.#.患者」
のワイルドカード#によって要素「患者」までのすべて
の経路がマッチしてしまうために、このような結果が起
こってしまうのである。
【0054】この問題を解決すべく、3種類目の限定方
法を導入する。この3種類目の限定方法の例を図15に
示し、その限定の手順のフローチャートを図16に示
す。ステップ41でルート要素から起点要素を探索し、
そのすべての起点要素に対してステップ42以下ステッ
プ42´までのループ処理を行う。ステップ43では、
文書型定義格納部2aに格納される文書型定義(DTD) の
情報を基に子要素に目標要素を持ち得る要素を探索す
る。図3のDTD の例を用いると、要素「カルテ」は要素
「健康保険」と要素「記録」を子要素に持ち得る。同様
に、要素「健康保険」は要素「患者」と要素「保険種
別」を持ち得る。
法を導入する。この3種類目の限定方法の例を図15に
示し、その限定の手順のフローチャートを図16に示
す。ステップ41でルート要素から起点要素を探索し、
そのすべての起点要素に対してステップ42以下ステッ
プ42´までのループ処理を行う。ステップ43では、
文書型定義格納部2aに格納される文書型定義(DTD) の
情報を基に子要素に目標要素を持ち得る要素を探索す
る。図3のDTD の例を用いると、要素「カルテ」は要素
「健康保険」と要素「記録」を子要素に持ち得る。同様
に、要素「健康保険」は要素「患者」と要素「保険種
別」を持ち得る。
【0055】このようにDTD の情報を参照することによ
って、ステップ43で子要素に目標要素を持ち得る要素
の集合が得られる。ステップ44ではステップ43で求
まったすべての要素に対してステップ44以下ステップ
44´までのループ処理を行う。ステップ45で、実際
に子要素に目標要素が存在するかチェックする。当該要
素の子要素に目標要素が存在しなければ、ステップ48
bでその要素から当該起点要素までのすべての要素に場
外フラグを付ける。
って、ステップ43で子要素に目標要素を持ち得る要素
の集合が得られる。ステップ44ではステップ43で求
まったすべての要素に対してステップ44以下ステップ
44´までのループ処理を行う。ステップ45で、実際
に子要素に目標要素が存在するかチェックする。当該要
素の子要素に目標要素が存在しなければ、ステップ48
bでその要素から当該起点要素までのすべての要素に場
外フラグを付ける。
【0056】目標要素が子要素として存在すれば、その
目標要素すべてに対して条件を満たすかステップ47で
判定する。この判定の結果、条件を満たさなければ、ス
テップ48aでその目標要素から当該起点要素までのす
べての要素に除外フラグを付ける。条件を満たせばステ
ップ48bでその目標要素から当該起点要素までのすべ
ての要素にキープフラグを付ける。そうして該当する要
素にフラグを付け終わったら、ステップ49で除該フラ
グしか付いていない要素をすべて検索木から除外する。
除外フラグとキープフラグの2つが付いている要素に関
しては除外しない。
目標要素すべてに対して条件を満たすかステップ47で
判定する。この判定の結果、条件を満たさなければ、ス
テップ48aでその目標要素から当該起点要素までのす
べての要素に除外フラグを付ける。条件を満たせばステ
ップ48bでその目標要素から当該起点要素までのすべ
ての要素にキープフラグを付ける。そうして該当する要
素にフラグを付け終わったら、ステップ49で除該フラ
グしか付いていない要素をすべて検索木から除外する。
除外フラグとキープフラグの2つが付いている要素に関
しては除外しない。
【0057】この一連の操作により、図15の検索式
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図4の要素「病名2」が除外さ
れ、かつ「病名2」から起点要素「カルテ」におけるす
べての要素、すなわち図4の場合は要素「記録2」が除
外される。また、要素「病名」を持ち得る要素「記録
3」も、子要素に“盲腸”を含む病名を持たなかったこ
とにより、これも除外される。以上の操作により、図1
5の検索式の実行結果は、図4の要素「患者1」のみが
返されることとなる。すなわちこれらの患者は、「“盲
腸”である患者」である。2種類目の限定方法の違い
は、まさに患者3が結果に含まれるかどうかということ
である。
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図4の要素「病名2」が除外さ
れ、かつ「病名2」から起点要素「カルテ」におけるす
べての要素、すなわち図4の場合は要素「記録2」が除
外される。また、要素「病名」を持ち得る要素「記録
3」も、子要素に“盲腸”を含む病名を持たなかったこ
とにより、これも除外される。以上の操作により、図1
5の検索式の実行結果は、図4の要素「患者1」のみが
返されることとなる。すなわちこれらの患者は、「“盲
腸”である患者」である。2種類目の限定方法の違い
は、まさに患者3が結果に含まれるかどうかということ
である。
【0058】4種類目の限定方法とその手順について説
明する。その前にまず、この限定法が必要な場合を示
す。図17の文書インスタンスに対して、図15の検索
式を適用する。図15の検索式の意図は、「“盲腸”で
ある患者の情報を取得せよ」であるとする。図15の検
索式を実行すると、前述の3種類目の限定方法でも説明
した通りの手順で、図17の要素「患者1」が取出され
る。しかし、3種類目の限定方法では、子要素に病名を
持ち得る要素の除外をすることは可能であるが、図16
の左側にある要素「保険要素」を除外するような指定は
されない。よって、図17の文書インスタンスに図15
の検索式を適用すると、「患者1」だけでなく、左側の
「患者」までもが取出されることになる。
明する。その前にまず、この限定法が必要な場合を示
す。図17の文書インスタンスに対して、図15の検索
式を適用する。図15の検索式の意図は、「“盲腸”で
ある患者の情報を取得せよ」であるとする。図15の検
索式を実行すると、前述の3種類目の限定方法でも説明
した通りの手順で、図17の要素「患者1」が取出され
る。しかし、3種類目の限定方法では、子要素に病名を
持ち得る要素の除外をすることは可能であるが、図16
の左側にある要素「保険要素」を除外するような指定は
されない。よって、図17の文書インスタンスに図15
の検索式を適用すると、「患者1」だけでなく、左側の
「患者」までもが取出されることになる。
【0059】この問題を解決すべく、4種類目の限定方
法を導入する。この4種類目の限定方法の例を図18に
示し、その限定の手順のフローチャートを図19に示
す。ステップ51からステップ55までは、限定方法1
のステップ21からステップ25まで同様である。異な
るステップは、条件を満たさない当該目標要素に対して
は、ステップ58でその目標要素に除外フラグを付ける
こと、条件を満たす当該目標要素に対しては、ステップ
56で、その目標要素から当該起点要素までのすべての
要素にキープフラグを付け、さらにステップ57で、当
該起点要素を除いてキープフラグの付いたすべての要素
から末端の葉要素に至るすべての要素にキープフラグを
つけることである。そしてステップ59で、除該フラグ
しか付いていない要素をすべて検索木から除外する。除
外フラグとキープフラグの2つが付いている要素に関し
ては除外しない。
法を導入する。この4種類目の限定方法の例を図18に
示し、その限定の手順のフローチャートを図19に示
す。ステップ51からステップ55までは、限定方法1
のステップ21からステップ25まで同様である。異な
るステップは、条件を満たさない当該目標要素に対して
は、ステップ58でその目標要素に除外フラグを付ける
こと、条件を満たす当該目標要素に対しては、ステップ
56で、その目標要素から当該起点要素までのすべての
要素にキープフラグを付け、さらにステップ57で、当
該起点要素を除いてキープフラグの付いたすべての要素
から末端の葉要素に至るすべての要素にキープフラグを
つけることである。そしてステップ59で、除該フラグ
しか付いていない要素をすべて検索木から除外する。除
外フラグとキープフラグの2つが付いている要素に関し
ては除外しない。
【0060】この一連の操作により、図18の検索式
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図17の要素「病名2」が除外
され、かつ「病名2」から起点要素「カルテ」における
要素「記録2」も除外される。要素「病名」を持ち得る
要素「記録3」も、子要素に“盲腸”を含む病名を持た
なかったことにより、これも除外される。また要素「健
康保険」以下の要素も、“盲腸”を文字列に含む要素
「病名」を持たないとして、除外される。以上の操作に
より、図18の検索式の実行結果は図17の要素「患者
1」が返されることとなる。すなわちこれらの患者は、
「“盲腸”である患者の情報であり、健康保険の患者の
情報ではない」ということになる。
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図17の要素「病名2」が除外
され、かつ「病名2」から起点要素「カルテ」における
要素「記録2」も除外される。要素「病名」を持ち得る
要素「記録3」も、子要素に“盲腸”を含む病名を持た
なかったことにより、これも除外される。また要素「健
康保険」以下の要素も、“盲腸”を文字列に含む要素
「病名」を持たないとして、除外される。以上の操作に
より、図18の検索式の実行結果は図17の要素「患者
1」が返されることとなる。すなわちこれらの患者は、
「“盲腸”である患者の情報であり、健康保険の患者の
情報ではない」ということになる。
【0061】5種類目の限定方法とその手順について説
明する。その前にまず、この限定法法が必要な場合を示
す。図20の文書インスタンスに対して、図18の検索
式を適用する。図18の検索式の意図は、「病名“盲
腸”にかかった最初の患者の情報を取得せよ」ととし、
すなわち要素「病名」の子要素の「患者」を取得するこ
とを目的とする。図18の検索式を実行すると、図20
の要素「病名1」が特定され、要素「患者a」と要素
「患者1」が取出される。
明する。その前にまず、この限定法法が必要な場合を示
す。図20の文書インスタンスに対して、図18の検索
式を適用する。図18の検索式の意図は、「病名“盲
腸”にかかった最初の患者の情報を取得せよ」ととし、
すなわち要素「病名」の子要素の「患者」を取得するこ
とを目的とする。図18の検索式を実行すると、図20
の要素「病名1」が特定され、要素「患者a」と要素
「患者1」が取出される。
【0062】しかし、「患者a」と「患者1」はたまた
ま要素名が同じであるだけで、その意味が異なってい
る。「患者a」は「病名1」に関する一つの情報であ
り、ここで述べている検索式ではこの「患者a」のみを
取出すことが目的であった。この目的を果たすべく、5
種類目の限定方法を導入する。この5種類目の限定方法
の例を図21に示し、その限定の手順のフローチャート
を図22に示す。
ま要素名が同じであるだけで、その意味が異なってい
る。「患者a」は「病名1」に関する一つの情報であ
り、ここで述べている検索式ではこの「患者a」のみを
取出すことが目的であった。この目的を果たすべく、5
種類目の限定方法を導入する。この5種類目の限定方法
の例を図21に示し、その限定の手順のフローチャート
を図22に示す。
【0063】ステップ61からステップ66及びステッ
プ68までは、限定方法4のステップ51から56及び
58までと同様である。異なるステップは、ステップ6
6のあとステップ67で目標要素から末端の葉にいたる
までのすべての要素にキープフラグを付けること、該当
するすべての要素にフラグを付けたあと、ステップ69
でキープフラグのみ付いている要素以外をすべて検索木
から除外することである。除外フラグとキープフラグの
2つが付いている要素に関しては、除外することとな
る。
プ68までは、限定方法4のステップ51から56及び
58までと同様である。異なるステップは、ステップ6
6のあとステップ67で目標要素から末端の葉にいたる
までのすべての要素にキープフラグを付けること、該当
するすべての要素にフラグを付けたあと、ステップ69
でキープフラグのみ付いている要素以外をすべて検索木
から除外することである。除外フラグとキープフラグの
2つが付いている要素に関しては、除外することとな
る。
【0064】この一連の操作により、図21の検索式
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図20の要素「病名2」が除外
され、かつ「病名2」から起点要素「カルテ」における
要素「記録2」も除外される。要素「病名」を持ち得る
要素「記録3」も、子要素に“盲腸”を含む病名を持た
なかったことにより、これも除外される。また要素「記
録3」も、また要素「健康保険」以下の要素も、“盲
腸”を文字列に含む要素「病名」を持たないとして、除
外される。さらに図22の5種類目の限定方法の操作に
より、「患者1」も除外される。これは、where 句で特
定された要素「病名1」と直接祖先/子孫関係になって
いないからである。以上の操作により、図21の検索式
の実行結果は、図20の要素「患者a」が返されること
となる。
「root.#@q.病名」のルートからたどることのでき
る要素「病名」のうち、図20の要素「病名2」が除外
され、かつ「病名2」から起点要素「カルテ」における
要素「記録2」も除外される。要素「病名」を持ち得る
要素「記録3」も、子要素に“盲腸”を含む病名を持た
なかったことにより、これも除外される。また要素「記
録3」も、また要素「健康保険」以下の要素も、“盲
腸”を文字列に含む要素「病名」を持たないとして、除
外される。さらに図22の5種類目の限定方法の操作に
より、「患者1」も除外される。これは、where 句で特
定された要素「病名1」と直接祖先/子孫関係になって
いないからである。以上の操作により、図21の検索式
の実行結果は、図20の要素「患者a」が返されること
となる。
【0065】本発明の以上の動作により、オブジェクト
指向データベース2に格納される構造化文書に対する曖
昧な論理構造指定による検索式の記述と実行が可能とな
り、課題を解決する。
指向データベース2に格納される構造化文書に対する曖
昧な論理構造指定による検索式の記述と実行が可能とな
り、課題を解決する。
【0066】第二の課題に対する解決手段は、文書に対
する検索のためのインデックスを作成して、文書中の文
字列検索を高速に行う全文検索エンジン部5cを文書検
索部5に組み込むことである。前述の第二の課題でも述
べたような、検索キーワードが当該文書中にある閾値以
上の出現頻度で含まれるかどうかの判断が可能かどうか
は、全文検索エンジン部5cに用いる全文検索エンジン
の機能次第である。本発明では、通常の文書に対してイ
ンデックスを生成しないで文書の先頭から当該検索キー
ワードを探す文字列検索方式ではなく、インデックスを
文書に対して事前に生成して、長大な文書に対しても高
速に文字列検索が行える全文検索エンジン、またその際
に前記の出現頻度を考慮したような判定方法など様々な
判定方法で文字列検索が行える全文検索エンジンを全文
検索エンジン部5cとして組み込むことを解決の手段とす
る。
する検索のためのインデックスを作成して、文書中の文
字列検索を高速に行う全文検索エンジン部5cを文書検
索部5に組み込むことである。前述の第二の課題でも述
べたような、検索キーワードが当該文書中にある閾値以
上の出現頻度で含まれるかどうかの判断が可能かどうか
は、全文検索エンジン部5cに用いる全文検索エンジン
の機能次第である。本発明では、通常の文書に対してイ
ンデックスを生成しないで文書の先頭から当該検索キー
ワードを探す文字列検索方式ではなく、インデックスを
文書に対して事前に生成して、長大な文書に対しても高
速に文字列検索が行える全文検索エンジン、またその際
に前記の出現頻度を考慮したような判定方法など様々な
判定方法で文字列検索が行える全文検索エンジンを全文
検索エンジン部5cとして組み込むことを解決の手段とす
る。
【0067】また、文書インスタンスや文書要素とイン
デックスとの一貫性保持の問題や、障害対策の問題に対
しては、インデックスをオブジェクト指向データベース
2中のインデックス格納部2dに格納することにより、
オブジェクト指向データベース2の持つトランザクショ
ン管理、バックアップリカバリの機能を用いて、一貫性
保持の問題、障害対策の問題などを解決する。
デックスとの一貫性保持の問題や、障害対策の問題に対
しては、インデックスをオブジェクト指向データベース
2中のインデックス格納部2dに格納することにより、
オブジェクト指向データベース2の持つトランザクショ
ン管理、バックアップリカバリの機能を用いて、一貫性
保持の問題、障害対策の問題などを解決する。
【0068】第三の課題に対する解決手段は、まずオブ
ジェクト指向データベース2に構造化文書を格納する際
に、文書型定義格納部2a、文書インスタンス格納部2
b、文書要素格納部2cに分けて格納する。一つの構造
化文書に対して、文書型定義が存在すれば最低一つの文
書型定義のオブジェクトと、最低一つの文書インスタン
スのオブジェクトと、そして文書インスタンス中の文書
要素を分解して、文書要素のつながり関係を保持した複
数の文書要素のオブジェクトとが、オブジェクト指向デ
ータベース2には格納されることになる。
ジェクト指向データベース2に構造化文書を格納する際
に、文書型定義格納部2a、文書インスタンス格納部2
b、文書要素格納部2cに分けて格納する。一つの構造
化文書に対して、文書型定義が存在すれば最低一つの文
書型定義のオブジェクトと、最低一つの文書インスタン
スのオブジェクトと、そして文書インスタンス中の文書
要素を分解して、文書要素のつながり関係を保持した複
数の文書要素のオブジェクトとが、オブジェクト指向デ
ータベース2には格納されることになる。
【0069】文書型定義オブジェクトや文書インスタン
スオブジェクトの検索はそれぞれ文書型定義格納部2
a、文書インスタンス格納部2b配下の集合から目的の
オブジェクトを取り出す処理となる。文書要素オブジェ
クトに対する検索は、文書インスタンスオブジェクトが
特定された後、文書インスタンスのルート要素となる文
書要素オブジェクトから以下子供の文書要素へと木構造
を辿りながら目的の文書要素オブジェクトを取り出す処
理となる。
スオブジェクトの検索はそれぞれ文書型定義格納部2
a、文書インスタンス格納部2b配下の集合から目的の
オブジェクトを取り出す処理となる。文書要素オブジェ
クトに対する検索は、文書インスタンスオブジェクトが
特定された後、文書インスタンスのルート要素となる文
書要素オブジェクトから以下子供の文書要素へと木構造
を辿りながら目的の文書要素オブジェクトを取り出す処
理となる。
【0070】ここで課題となるのは、文書の論理構造の
指定を明確に指定する検索式しか受け入れないのなら
ば、文書要素オブジェクトのナビゲーション処理で、明
確に指定された論理構造間のみをナビゲートするだけで
目的の文書要素オブジェクトへと辿り着くことができ
る。しかし、例えば、General Path Expression の表記
法の一つで、任意のオブジェクト間のパスにマッチする
ワイルドカード#を用いて曖昧な論理構造指定を許す
と、その#で指定したすべてのオブジェクト間のパスを
探索しなければならなくなる。よって、曖昧な論理構造
の指定による検索は、厳密に構造を指定する方法より検
索時間が多くかかることが予想される。
指定を明確に指定する検索式しか受け入れないのなら
ば、文書要素オブジェクトのナビゲーション処理で、明
確に指定された論理構造間のみをナビゲートするだけで
目的の文書要素オブジェクトへと辿り着くことができ
る。しかし、例えば、General Path Expression の表記
法の一つで、任意のオブジェクト間のパスにマッチする
ワイルドカード#を用いて曖昧な論理構造指定を許す
と、その#で指定したすべてのオブジェクト間のパスを
探索しなければならなくなる。よって、曖昧な論理構造
の指定による検索は、厳密に構造を指定する方法より検
索時間が多くかかることが予想される。
【0071】このような課題を解決するために、文書型
定義格納部2aに格納されている、検索対象となってい
る文書インスタンスと関係する文書型定義オブジェクト
の情報と照合し、オブジェクト間の経路探索における不
必要なパスを算出することによって極力オブジェクトナ
ビゲーション処理の回数を減らすことによって課題を解
決する。
定義格納部2aに格納されている、検索対象となってい
る文書インスタンスと関係する文書型定義オブジェクト
の情報と照合し、オブジェクト間の経路探索における不
必要なパスを算出することによって極力オブジェクトナ
ビゲーション処理の回数を減らすことによって課題を解
決する。
【0072】
【実施例】本発明で扱う構造化文書は文書型定義(DTD)
と、前記文書型定義に従った文書インスタンスを持つ構
造化文書である。ただし、特に文書型定義がなくても文
書インスタンスのみの構造化文書も取り扱うものとす
る。構造化文書を本発明のシステムに登録する手順のフ
ローチャートを図23に示す。ステップ71で、構造化
文書入力部1から構造化文書が入力される。構造化文書
入力部1は、ステップ72で構造化文書中に文書型定義
が存在するか確認し、存在すれば、ステップ73で文書
型定義を文書型定義格納部2aに格納する。
と、前記文書型定義に従った文書インスタンスを持つ構
造化文書である。ただし、特に文書型定義がなくても文
書インスタンスのみの構造化文書も取り扱うものとす
る。構造化文書を本発明のシステムに登録する手順のフ
ローチャートを図23に示す。ステップ71で、構造化
文書入力部1から構造化文書が入力される。構造化文書
入力部1は、ステップ72で構造化文書中に文書型定義
が存在するか確認し、存在すれば、ステップ73で文書
型定義を文書型定義格納部2aに格納する。
【0073】また、構造化文書入力部1は、ステップ7
4で文書インスタンスを文書インスタンス格納部2bに
格納する。さらに、ステップ75で文書インスタンスの
中身である文書の部分に対して全部検索用のインデック
スを作成し、そのインデックスをインデックス格納部2
dに格納する。
4で文書インスタンスを文書インスタンス格納部2bに
格納する。さらに、ステップ75で文書インスタンスの
中身である文書の部分に対して全部検索用のインデック
スを作成し、そのインデックスをインデックス格納部2
dに格納する。
【0074】インデックスの作成に関しては、全文検索
エンジン部5cによって作成されるものであるが、その
作成方法に関しては本発明の範囲外である。インデック
スをオブジェクト指向データベースに格納する手段を有
することが本発明の範囲である。構造化文書入力部1は
ステップ76で文書インスタンスを文書要素毎に分解
し、ステップ77で文書インスタンス中の文書要素間の
木構造関係を保持したまま、それぞれの文書要素を一つ
のオブジェクトとして文書要素格納部2cに格納する。
エンジン部5cによって作成されるものであるが、その
作成方法に関しては本発明の範囲外である。インデック
スをオブジェクト指向データベースに格納する手段を有
することが本発明の範囲である。構造化文書入力部1は
ステップ76で文書インスタンスを文書要素毎に分解
し、ステップ77で文書インスタンス中の文書要素間の
木構造関係を保持したまま、それぞれの文書要素を一つ
のオブジェクトとして文書要素格納部2cに格納する。
【0075】また各文書要素の中身、すなわち各文書要
素のタグで囲まれた文書の部分に対して全部検索用のイ
ンデックスを作成し、そのインデックスをインデックス
格納部2dに格納する。文書型定義格納部2a、文書イ
ンスタンス格納部2b、文書要素格納部2cに実際に格
納されるオブジェクトは、文書型定義格納部2aなら、
例えば図3の文書型定義全体、文書インスタンス格納部
2bなら、例えば図20の文書インスタンス全体、文書
要素格納部2cなら、例えば図20の各文書要素とその
つながり関係である。
素のタグで囲まれた文書の部分に対して全部検索用のイ
ンデックスを作成し、そのインデックスをインデックス
格納部2dに格納する。文書型定義格納部2a、文書イ
ンスタンス格納部2b、文書要素格納部2cに実際に格
納されるオブジェクトは、文書型定義格納部2aなら、
例えば図3の文書型定義全体、文書インスタンス格納部
2bなら、例えば図20の文書インスタンス全体、文書
要素格納部2cなら、例えば図20の各文書要素とその
つながり関係である。
【0076】以上の構造化文書のインデックスに関する
格納方法は、本発明の第二の課題でも述べた全文検索エ
ンジンが作成するインデックスの保持に関する問題の解
決策となっている。構造化文書の格納では、オブジェク
ト指向データベース2のトランザクション管理によっ
て、一貫性を保持した格納が可能となる。また、文書イ
ンスタンスや文書要素とインデックスはそれぞれオブジ
ェクトとして管理され、その関係はオブジェクト間のリ
ンクとしてオブジェクト指向データベース2によって管
理される。
格納方法は、本発明の第二の課題でも述べた全文検索エ
ンジンが作成するインデックスの保持に関する問題の解
決策となっている。構造化文書の格納では、オブジェク
ト指向データベース2のトランザクション管理によっ
て、一貫性を保持した格納が可能となる。また、文書イ
ンスタンスや文書要素とインデックスはそれぞれオブジ
ェクトとして管理され、その関係はオブジェクト間のリ
ンクとしてオブジェクト指向データベース2によって管
理される。
【0077】本発明第一の課題に関する発明の実施例に
ついては、第一の課題を解決する手段でも述べたが、本
発明第二の課題と合わせて述べる。図3、図20に示す
文書型定義と文書インスタンス/文書要素を持つ構造化
文書を例題として取り上げる。この図3、図20で表現
される構造化文書に対して、図24に示す拡張OQL によ
る検索式を適用することを考える。この図24の検索式
の意味を自然言語で述べると、「ルート要素からたどれ
る要素「病名」において(from root.#.病名D)、病
名の中身の文書で“盲腸”という文字列が閾値0.6の
出現頻度で現れることを条件とし(where D.%.li
ke( “盲腸”,0.6))そのような病名から辿ること
ができる原因(from D.#.原因C)を検索結果とし
て返せ(select C)。」となる。
ついては、第一の課題を解決する手段でも述べたが、本
発明第二の課題と合わせて述べる。図3、図20に示す
文書型定義と文書インスタンス/文書要素を持つ構造化
文書を例題として取り上げる。この図3、図20で表現
される構造化文書に対して、図24に示す拡張OQL によ
る検索式を適用することを考える。この図24の検索式
の意味を自然言語で述べると、「ルート要素からたどれ
る要素「病名」において(from root.#.病名D)、病
名の中身の文書で“盲腸”という文字列が閾値0.6の
出現頻度で現れることを条件とし(where D.%.li
ke( “盲腸”,0.6))そのような病名から辿ること
ができる原因(from D.#.原因C)を検索結果とし
て返せ(select C)。」となる。
【0078】where 句に現れる引数を2つとるメンバ関
数likeは、文書検索部5が用意する検索モジュールの一
つである。この検索モジュールは、第一引数で指定され
た文字列を当該文書中に第二引数で指定された閾値以上
の頻度で現れるかどうかを調べる。第二引数の閾値以上
で第一引数の文字列が出現すればTRUEを返し、そうでな
ければFALSE を返す。また文字列検索自身は、全文検索
エンジン部5cが全文検索の対象とする文書インスタン
スや文書要素の内容である各文書に対してあらかじめ作
成されたインデックスを文書インデックス格納部2dか
ら引き出してインデックスを用いて高速に検索を行う。
数likeは、文書検索部5が用意する検索モジュールの一
つである。この検索モジュールは、第一引数で指定され
た文字列を当該文書中に第二引数で指定された閾値以上
の頻度で現れるかどうかを調べる。第二引数の閾値以上
で第一引数の文字列が出現すればTRUEを返し、そうでな
ければFALSE を返す。また文字列検索自身は、全文検索
エンジン部5cが全文検索の対象とする文書インスタン
スや文書要素の内容である各文書に対してあらかじめ作
成されたインデックスを文書インデックス格納部2dか
ら引き出してインデックスを用いて高速に検索を行う。
【0079】ここで言う高速とは、単純に文章の先頭か
ら文字列マッチによって検索する方法と比較して、イン
デックスを用いた文字列マッチの方が一般的に高速であ
るという意味で用いている。本発明では、この全文検索
エンジン部5cの文字列検索方法については範囲外であ
る。
ら文字列マッチによって検索する方法と比較して、イン
デックスを用いた文字列マッチの方が一般的に高速であ
るという意味で用いている。本発明では、この全文検索
エンジン部5cの文字列検索方法については範囲外であ
る。
【0080】また本発明は、メソッドlikeは文書検索実
行部5aにあらかじめ用意されており、likeを呼び出す
検索式を用いた検索方式の発明に関するものであり、メ
ソッドlikeの実装方法や、likeの第二引数の0.6の意
味などについては本発明の範囲外である。しかしなが
ら、実施例として0.6の意味の一例を述べると、例え
ば、「句点「。」で区切られる文が10あったとしたと
き、メソッドlikeの第一引数で指定された文字列が10
の文の中で7つの文中に用いられた場合、文字列の使用
頻度を表す値を0.7とする。likeの第二引数で指定さ
れた閾値は0.6であるので、likeの返却値はTRUEとな
る。」という意味における検索条件指定が可能というこ
とになる。図20の文書インスタンスに対して検索式wh
ere D.%.like(“盲腸”、0.6)によって病名1
が条件を満たした場合、図24の検索式の結果、図20
の要素「原因1」が返る。
行部5aにあらかじめ用意されており、likeを呼び出す
検索式を用いた検索方式の発明に関するものであり、メ
ソッドlikeの実装方法や、likeの第二引数の0.6の意
味などについては本発明の範囲外である。しかしなが
ら、実施例として0.6の意味の一例を述べると、例え
ば、「句点「。」で区切られる文が10あったとしたと
き、メソッドlikeの第一引数で指定された文字列が10
の文の中で7つの文中に用いられた場合、文字列の使用
頻度を表す値を0.7とする。likeの第二引数で指定さ
れた閾値は0.6であるので、likeの返却値はTRUEとな
る。」という意味における検索条件指定が可能というこ
とになる。図20の文書インスタンスに対して検索式wh
ere D.%.like(“盲腸”、0.6)によって病名1
が条件を満たした場合、図24の検索式の結果、図20
の要素「原因1」が返る。
【0081】本発明第三の課題に関する発明の実施例に
ついて述べる。図20の文書インスタンスに対して図2
5の検索式を適用する例を用いて説明する。図25の検
索式のfrom句で、「root.#.保険種別」としてselect
句で保険種別を取出そうとしている。ここで、ルート要
素から保険種別を探索するのに、図20の文書インスタ
ンスのすべての経路を探索する必要はない。
ついて述べる。図20の文書インスタンスに対して図2
5の検索式を適用する例を用いて説明する。図25の検
索式のfrom句で、「root.#.保険種別」としてselect
句で保険種別を取出そうとしている。ここで、ルート要
素から保険種別を探索するのに、図20の文書インスタ
ンスのすべての経路を探索する必要はない。
【0082】図20の文書インスタンスの文書型定義で
ある図3の文書型定義を格納する文書型定義格納部2a
では、前記文書型定義図3に対して図26で示す手順に
従って、すべての文書要素に対して当該文書要素以下の
子孫要素のリストをあらかじめ保持させる。ただし、ス
テップ83によって作成される子孫要素リストの要素は
重複を許さないこととする。よって目標要素の検索で
は、この文書型定義格納部2aの各要素定義に対する子
孫要素リストの情報を参照し、目標要素を子孫要素リス
トに含んでいる要素のみを経路探索して目標要素を検索
する。
ある図3の文書型定義を格納する文書型定義格納部2a
では、前記文書型定義図3に対して図26で示す手順に
従って、すべての文書要素に対して当該文書要素以下の
子孫要素のリストをあらかじめ保持させる。ただし、ス
テップ83によって作成される子孫要素リストの要素は
重複を許さないこととする。よって目標要素の検索で
は、この文書型定義格納部2aの各要素定義に対する子
孫要素リストの情報を参照し、目標要素を子孫要素リス
トに含んでいる要素のみを経路探索して目標要素を検索
する。
【0083】図3の文書型定義で子孫要素リストを説明
すると、要素「カルテ」の子孫要素は、「健康保険」、
「記録」、「患者」、「保険種別」、「病名」、「原
因」である。要素「健康保険」の子孫要素は、「患
者」、「保険種別」である。要素「記録」の子孫要素
は、「患者」、「病名」、「原因」である。よって、要
素「保険種別」を経路探索するのには、「保険種別」を
子孫要素に含んでいる「カルテ」や「健康保険」を探索
し、「保険種別」を子孫要素に含んでいない「記録」は
探索する必要はないということになる。
すると、要素「カルテ」の子孫要素は、「健康保険」、
「記録」、「患者」、「保険種別」、「病名」、「原
因」である。要素「健康保険」の子孫要素は、「患
者」、「保険種別」である。要素「記録」の子孫要素
は、「患者」、「病名」、「原因」である。よって、要
素「保険種別」を経路探索するのには、「保険種別」を
子孫要素に含んでいる「カルテ」や「健康保険」を探索
し、「保険種別」を子孫要素に含んでいない「記録」は
探索する必要はないということになる。
【0084】このような、ある起点要素から目標要素を
探索する際に、経路として通る必要のない要素の集合を
本発明では回避要素集合と呼ぶ。「root.#.保険種
別」における図20の文書インスタンスの例では、回避
要素集合は「記録」となる。このような回避要素集合を
求める計算は、文書検索最適化部5bが行う。文書検索
実行部5aは回避要素集合の情報を文書探索最適化部5
bから取得して、実際の図20における「保険種別」の
検索において「カルテ.記録.#」という経路の探索を
一切行わない。
探索する際に、経路として通る必要のない要素の集合を
本発明では回避要素集合と呼ぶ。「root.#.保険種
別」における図20の文書インスタンスの例では、回避
要素集合は「記録」となる。このような回避要素集合を
求める計算は、文書検索最適化部5bが行う。文書検索
実行部5aは回避要素集合の情報を文書探索最適化部5
bから取得して、実際の図20における「保険種別」の
検索において「カルテ.記録.#」という経路の探索を
一切行わない。
【0085】以上の回避集合を求めて最適の経路探索を
求める方法は、構造化文書に文書型定義が存在し、かつ
構造化文書の文書インスタンスが文書型定義に対して妥
当である場合のみ有効である。XML の整形式のXML 文書
などに代表されるように、文書型定義が存在しない、ま
たは文書型定義に文書インスタンスが従わなくても許さ
れるような構造化文書では前述の回避要素集合を求める
方法は適用できない。そこで本発明ではもう一つの経路
探索最適化方法を示す。
求める方法は、構造化文書に文書型定義が存在し、かつ
構造化文書の文書インスタンスが文書型定義に対して妥
当である場合のみ有効である。XML の整形式のXML 文書
などに代表されるように、文書型定義が存在しない、ま
たは文書型定義に文書インスタンスが従わなくても許さ
れるような構造化文書では前述の回避要素集合を求める
方法は適用できない。そこで本発明ではもう一つの経路
探索最適化方法を示す。
【0086】図27の手順に従って、文書要素格納部2
cの各要素の中で必要と思われる要素に対し、すべての
子孫要素への参照のリストを保持させる。子孫要素への
参照リストの作成は文書要素の検索を実行する前にあら
かじめ行っておくものとする。要素「カルテ」に対して
図27の手順を適用した例を図28に示す。ただし図2
8では通常の木構造における親子関係を表す辺( エッ
ジ) の記述は省略してある。この方法によって文書要素
に直接子孫要素への参照リストを保持させれば、文書検
索実行部5aは、文書検索最適化部5bが求める回避要
素集合の情報を用いることなく、直接「カルテ」から
「保険種別」への探索を実行し、それ以外の経路探索は
「保険種別」へ辿り着かない経路として探索を実行しな
い。
cの各要素の中で必要と思われる要素に対し、すべての
子孫要素への参照のリストを保持させる。子孫要素への
参照リストの作成は文書要素の検索を実行する前にあら
かじめ行っておくものとする。要素「カルテ」に対して
図27の手順を適用した例を図28に示す。ただし図2
8では通常の木構造における親子関係を表す辺( エッ
ジ) の記述は省略してある。この方法によって文書要素
に直接子孫要素への参照リストを保持させれば、文書検
索実行部5aは、文書検索最適化部5bが求める回避要
素集合の情報を用いることなく、直接「カルテ」から
「保険種別」への探索を実行し、それ以外の経路探索は
「保険種別」へ辿り着かない経路として探索を実行しな
い。
【0087】このような文書要素に対してすべての子孫
要素への直接的な参照を保持させておく方法は、要素の
数によってその参照リスト作成処理に多くの時間を要す
ることが予想される。また文書要素間の関係が更新され
た場合、更新に関係する文書要素間の参照関係の更新処
理も多く発生し、性能面で問題が発生する。しかしこの
ような問題は検索の前段階であらかじめ前述の処理を行
っておき、実際の検索では当該処理は行わない利用方法
を採用することによって性能問題を回避することは可能
である。
要素への直接的な参照を保持させておく方法は、要素の
数によってその参照リスト作成処理に多くの時間を要す
ることが予想される。また文書要素間の関係が更新され
た場合、更新に関係する文書要素間の参照関係の更新処
理も多く発生し、性能面で問題が発生する。しかしこの
ような問題は検索の前段階であらかじめ前述の処理を行
っておき、実際の検索では当該処理は行わない利用方法
を採用することによって性能問題を回避することは可能
である。
【0088】以上の回避要素集合による最適経路探索の
方法または直接の子孫要素への参照を持つ方法、または
これらの方法を組み合わせた方法のいずれかにより、ワ
イルドカード#を持つ文書要素の探索回数を減らし、結
果として経路探索時間を短縮し、本発明の第三の課題を
解決する。
方法または直接の子孫要素への参照を持つ方法、または
これらの方法を組み合わせた方法のいずれかにより、ワ
イルドカード#を持つ文書要素の探索回数を減らし、結
果として経路探索時間を短縮し、本発明の第三の課題を
解決する。
【0089】
【発明の効果】本発明により、構造化文書の検索におい
て、論理構造の曖昧な指定による検索を実現した。この
実現の効果は 1)必要な論理構造を曖昧に指定するだけで、厳密に論
理構造を指定する場合とほぼ同等の検索結果を得ること
ができる。 2)文書の論理構造が複雑な場合、ユーザはそのすべて
の論理構造を厳密に把握しなくても良く、ユーザの文書
型定義を把握する負担を軽減する。 3)若干の論理構造が異なる文書インスタンスや文書要
素に対しても、検索式にGeneral Path Expression を用
いて同様の検索の意図で検索を実行することができる。
これは特に、検索式を含むアプリケーションプログラム
が存在した時に、アプリケーションプログラムを書き換
えずに異なる論理構造を持つ構造化文書の検索に適用す
ることができることを意味する。
て、論理構造の曖昧な指定による検索を実現した。この
実現の効果は 1)必要な論理構造を曖昧に指定するだけで、厳密に論
理構造を指定する場合とほぼ同等の検索結果を得ること
ができる。 2)文書の論理構造が複雑な場合、ユーザはそのすべて
の論理構造を厳密に把握しなくても良く、ユーザの文書
型定義を把握する負担を軽減する。 3)若干の論理構造が異なる文書インスタンスや文書要
素に対しても、検索式にGeneral Path Expression を用
いて同様の検索の意図で検索を実行することができる。
これは特に、検索式を含むアプリケーションプログラム
が存在した時に、アプリケーションプログラムを書き換
えずに異なる論理構造を持つ構造化文書の検索に適用す
ることができることを意味する。
【0090】また、曖昧な検索において探索すべきパス
を減らしたり、あらかじめ子孫要素への参照を持った
り、また前述の2つの方法を組み合わせたりする方法に
よる検索で、厳密に構造を指定した場合の検索時間に限
りなく近づけることが可能となった。また、あらかじめ
子孫要素への参照を持つ方法では、整形式のXML 文書な
ど文書型定義が含まれない、または文書型定義に従う必
要がない構造化文書に対しても検索時間を短縮する方法
を適用することができる。
を減らしたり、あらかじめ子孫要素への参照を持った
り、また前述の2つの方法を組み合わせたりする方法に
よる検索で、厳密に構造を指定した場合の検索時間に限
りなく近づけることが可能となった。また、あらかじめ
子孫要素への参照を持つ方法では、整形式のXML 文書な
ど文書型定義が含まれない、または文書型定義に従う必
要がない構造化文書に対しても検索時間を短縮する方法
を適用することができる。
【0091】本発明では、文書インスタンスや文書要素
の内容に対する文字列検索に全文検索エンジン部5cを組
み込むことにより、高速な検索を実現し、かつ検索キー
ワードの出現頻度を考慮した条件指定など様々な検索指
定を提供した。この出現頻度による検索方法は、例えば
ある検索キーワードが頻繁に出現する文書はその検索キ
ーワードに関する説明文であるなど、ある仮定のもと、
文書の意味内容に基づく検索を実現することができる。
の内容に対する文字列検索に全文検索エンジン部5cを組
み込むことにより、高速な検索を実現し、かつ検索キー
ワードの出現頻度を考慮した条件指定など様々な検索指
定を提供した。この出現頻度による検索方法は、例えば
ある検索キーワードが頻繁に出現する文書はその検索キ
ーワードに関する説明文であるなど、ある仮定のもと、
文書の意味内容に基づく検索を実現することができる。
【0092】また全文検索エンジン部が作成する、文書
インスタンスや文書要素のインデックスを、オブジェク
ト指向データベースの中の文書インデックス格納部に格
納して、トランザクション管理、バックアップリカバリ
などを行うことにより、文書とインデックスの間の不整
合を回避し、インデックスによる文書の正しく高速な文
字列検索の実現、また障害などで同じインデックスを2
回以上生成しなければならなくなる事態の発生の回避な
どに役に立つ。
インスタンスや文書要素のインデックスを、オブジェク
ト指向データベースの中の文書インデックス格納部に格
納して、トランザクション管理、バックアップリカバリ
などを行うことにより、文書とインデックスの間の不整
合を回避し、インデックスによる文書の正しく高速な文
字列検索の実現、また障害などで同じインデックスを2
回以上生成しなければならなくなる事態の発生の回避な
どに役に立つ。
【図1】本発明の実施例のシステム構成図である。
【図2】検索式入力から検索結果表示までの処理手順を
示す図である。
示す図である。
【図3】構造化文書「カルテ」の文書型定義の例を示す
図である。
図である。
【図4】構造化文書「カルテ」の文書インスタンスとそ
の文書要素の例を示す図である。
の文書要素の例を示す図である。
【図5】文書型定義の異なる別の文書インスタンスとそ
の文書要素の例を示す図である。
の文書要素の例を示す図である。
【図6】本発明に用いる検索式の一例を示す図である。
【図7】厳密に論理構造を指定した検索式の例を示す図
である。
である。
【図8】ワイルドカード#の使用が問題となる検索式の
例を示す図である。
例を示す図である。
【図9】ワイルドカード#の経路を限定する1種類目の
検索式の例を示す図である。
検索式の例を示す図である。
【図10】ワイルドカード#の限定方法の一例のフロー
チャートである。
チャートである。
【図11】本発明に用いる検索式の他の例を示す図であ
る。
る。
【図12】ワイルドカード#の経路を限定する2種類目
の検索式の例を示す図である。
の検索式の例を示す図である。
【図13】ワイルドカード#の限定方法の他の例のフロ
ーチャートである。
ーチャートである。
【図14】本発明に用いる検索式の更に他の例を示す図
である。
である。
【図15】ワイルドカード#の経路を限定する3種類目
の検索式の例を示す図である。
の検索式の例を示す図である。
【図16】ワイルドカード#の限定方法の別の例のフロ
ーチャートである。
ーチャートである。
【図17】構造化文書「カルテ」の文書インスタンスと
その文書要素の他の例を示す図である。
その文書要素の他の例を示す図である。
【図18】ワイルドカード#の経路を限定する4種類目
の検索式の例を示す図である。
の検索式の例を示す図である。
【図19】ワイルドカード#の限定方法の更に別の例の
フローチャートである。
フローチャートである。
【図20】構造化文書「カルテ」の文書インスタンスと
その文書要素の更に他の例を示す図である。
その文書要素の更に他の例を示す図である。
【図21】ワイルドカード#の経路を限定する5種類目
の検索式の例を示す図である。
の検索式の例を示す図である。
【図22】ワイルドカード#の限定方法の他の例のフロ
ーチャートである。
ーチャートである。
【図23】構造化文書を格納する処理手順を示す図であ
る。
る。
【図24】本発明に用いる検索式の別の例を示す図であ
る。
る。
【図25】本発明に用いる検索式の更に別の例を示す図
である。
である。
【図26】文書型定義格納部の各要素定義における子孫
要素リスト作成手順を示す図である。
要素リスト作成手順を示す図である。
【図27】文書型定義格納部の各要素定義における子孫
要素への参照リスト作成手順を示す図である。
要素への参照リスト作成手順を示す図である。
【図28】子孫要素への参照をすべて保持する文書要素
「カルテ」の例を示す図である。
「カルテ」の例を示す図である。
1 構造化文書入部 2 オブジェクト指向データベース 2a 文書型定義格納部 2b 文書インスタンス格納部 2c 文書要素格納部 2d 文書インデックス格納部 3 文書検索式入部 4 文書検索式解析部 5 文書検索部 5a 文書検索実行部 5b 文書検索最適化部 5c 全文検索エンシン部 6 検索文書表示部 7 構造化文書操作部
Claims (8)
- 【請求項1】 構造化文書の文書型定義部分をオブジェ
クトとして格納する文書型定義格納部と、前記構造化文
書の文書インスタンス部分をオブジェクトとして格納す
る文書インスタンス格納部と、前記文書インスタンス
(または単に文書)に含まれる各文書要素(または単に
要素)を、そのつながり関係を保持したままオブジェク
トとして格納する文書要素格納部とを具備したオブジェ
クト指向データベースと、 前記構造化文書を前記データベースに対して格納制御す
る構造化文書入力部と、を含むことを特徴とする構造化
文書データベースシステム。 - 【請求項2】 前記データベースに格納された構造化文
書に対する論理構造及び文書内容の追加・変更・削除の
各操作、また前記論理構造及び文書内容の複数文書間で
の共有化を可能にする構造化文書操作部を含むことを特
徴とする請求項1記載の構造化文書データベースシステ
ム。 - 【請求項3】 前記データベースに格納された構造化文
書に対する検索を目的とした文書検索式を入力として受
け取る文書検索式入力部と、前記文書検索式を解析し、
前記データベースに格納される文書及び文書要素の検索
を実行する文書検索部に対する検索プログラムを組み立
て、そして実行する文書検索解析部とを含むことを特徴
とする請求項1または2記載の構造化文書データベース
システム。 - 【請求項4】 前記データベースに格納された構造化文
書に対する検索を実行し、目的の文書及び文書要素をオ
ブジェクト指向データベースから取り出す文書検索実行
部を含むことを特徴とする請求項1〜3いずれか記載の
構造化文書データベースシステム。 - 【請求項5】 前記文書検索式入力部は、Stanford大学
のLorel などに代表されるGeneral Path Expression
(オブジェクト参照関係のパスやラベルにワイルドカー
ドを含めたり、正規表現を用いたりする記述)を含む拡
張OQL(Object Query Language)を用いて、構造化文書の
検索における論理構造や文書内容の条件に曖昧な指定を
可能とする文書検索式が入力自在であることをを特徴と
する請求項3,4いずれか記載の構造化文書データベー
スシステム。 - 【請求項6】 前記文書検索解析部が組み立てた検索プ
ログラムの、前記データベースにおけるオブジェクトナ
ビゲーションの回数を最小に押さえてその処理時間を短
縮させることを目的とした最適なナビゲーション処理手
順の算出及び検索の目標オブジェクトに直接処理を移動
できるオブジェクト参照関係の作成を行う文書検索最適
化部を含むことを特徴とする請求項3〜5いずれか記載
の構造化文書データベースシステム。 - 【請求項7】 前記文書検索式入力部は、前記曖昧な条
件指定を可能とする検索式で、文書内容の条件指定で単
にある文字列が含まれることを条件とする他に、前記文
字列が当該文書内容にある閾値を超えた頻度で含まれる
ことを条件とするなどの曖昧な指定を可能とするよう構
成されており、前記文書検索部に含まれる前記当該文書
内容の文字列検索を高速に行う全文検索エンジン部と、
前記全文検索エンジン部が文書及び文書要素に対してあ
らかじめ作成する文書インデックスを格納する文書イン
デックス格納部とを含むことを特徴とする請求項5記載
の構造化文書データベースシステム。 - 【請求項8】 前記文書検索実行部を含む文書検索部が
出力する文書及び文書要素の論理構造も含めた文書内容
の表示を行う検索文書表示部を含むことを特徴とする請
求項4記載の構造化文書データベースシステム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP10227479A JP2000057163A (ja) | 1998-08-12 | 1998-08-12 | 構造化文書データベースシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP10227479A JP2000057163A (ja) | 1998-08-12 | 1998-08-12 | 構造化文書データベースシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2000057163A true JP2000057163A (ja) | 2000-02-25 |
Family
ID=16861534
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP10227479A Pending JP2000057163A (ja) | 1998-08-12 | 1998-08-12 | 構造化文書データベースシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2000057163A (ja) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1617345A1 (en) | 2004-07-15 | 2006-01-18 | Kabushiki Kaisha Toshiba | Apparatus, method and program for managing and searching structured documents |
JP2007133624A (ja) * | 2005-11-10 | 2007-05-31 | Hitachi Ltd | 連結関係情報を用いた情報管理方法及び装置 |
US7401071B2 (en) | 2003-12-25 | 2008-07-15 | Kabushiki Kaisha Toshiba | Structured data retrieval apparatus, method, and computer readable medium |
US7664773B2 (en) | 2004-02-10 | 2010-02-16 | Kabushiki Kaisha Toshiba | Structured data storage method, structured data storage apparatus, and retrieval method |
US7975220B2 (en) | 2006-02-22 | 2011-07-05 | Kabushiki Kaisha Toshiba | Apparatus, program product and method for structured document management |
US8595215B2 (en) | 2007-03-22 | 2013-11-26 | Kabushiki Kaisha Toshiba | Apparatus, method, and computer program product for processing query |
US9378301B2 (en) | 2008-09-26 | 2016-06-28 | Kabushiki Kaisha Toshiba | Apparatus, method, and computer program product for searching structured document |
CN114927180A (zh) * | 2022-02-23 | 2022-08-19 | 北京爱医声科技有限公司 | 病历结构化方法、装置及存储介质 |
-
1998
- 1998-08-12 JP JP10227479A patent/JP2000057163A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7401071B2 (en) | 2003-12-25 | 2008-07-15 | Kabushiki Kaisha Toshiba | Structured data retrieval apparatus, method, and computer readable medium |
US7664773B2 (en) | 2004-02-10 | 2010-02-16 | Kabushiki Kaisha Toshiba | Structured data storage method, structured data storage apparatus, and retrieval method |
EP1617345A1 (en) | 2004-07-15 | 2006-01-18 | Kabushiki Kaisha Toshiba | Apparatus, method and program for managing and searching structured documents |
US8082492B2 (en) | 2004-07-15 | 2011-12-20 | Kabushiki Kaisha Toshiba | Structured-document management apparatus, search apparatus, storage method, search method and program |
JP2007133624A (ja) * | 2005-11-10 | 2007-05-31 | Hitachi Ltd | 連結関係情報を用いた情報管理方法及び装置 |
US7975220B2 (en) | 2006-02-22 | 2011-07-05 | Kabushiki Kaisha Toshiba | Apparatus, program product and method for structured document management |
US8595215B2 (en) | 2007-03-22 | 2013-11-26 | Kabushiki Kaisha Toshiba | Apparatus, method, and computer program product for processing query |
US9378301B2 (en) | 2008-09-26 | 2016-06-28 | Kabushiki Kaisha Toshiba | Apparatus, method, and computer program product for searching structured document |
CN114927180A (zh) * | 2022-02-23 | 2022-08-19 | 北京爱医声科技有限公司 | 病历结构化方法、装置及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11243870B2 (en) | Resolution of data flow errors using the lineage of detected error conditions | |
US6636845B2 (en) | Generating one or more XML documents from a single SQL query | |
Grau et al. | Combining OWL ontologies using E-connections | |
EP1399842B1 (en) | Creation of structured data from plain text | |
US7644361B2 (en) | Method of using recommendations to visually create new views of data across heterogeneous sources | |
US7844633B2 (en) | System and method for storage, management and automatic indexing of structured documents | |
US20150254530A1 (en) | Framework for data extraction by examples | |
US20160275180A1 (en) | System and method for storing and searching data extracted from text documents | |
US20140114942A1 (en) | Dynamic Pruning of a Search Index Based on Search Results | |
JP2004240954A (ja) | 階層データを提示する方法 | |
WO2014062278A1 (en) | Associated information propagation system | |
US20110106836A1 (en) | Semantic Link Discovery | |
Omari et al. | Cross-supervised synthesis of web-crawlers | |
JP2000057163A (ja) | 構造化文書データベースシステム | |
Ghodke et al. | Fangorn: A system for querying very large treebanks | |
Arocena | WebOQL: Exploiting document structure in web queries | |
US8312030B2 (en) | Efficient evaluation of XQuery and XPath full text extension | |
Lin et al. | Towards Accurate and Efficient Document Analytics with Large Language Models | |
Nielandt et al. | Predicate enrichment of aligned XPaths for wrapper induction | |
Hai | Data integration and metadata management in data lakes | |
Crichton et al. | A Core Calculus for Documents: Or, Lambda: The Ultimate Document | |
Tari et al. | Parse tree database for information extraction | |
JP3842574B2 (ja) | 情報抽出方法および構造化文書管理装置およびプログラム | |
US20240119071A1 (en) | Relationship-based display of computer-implemented documents | |
US11250010B2 (en) | Data access generation providing enhanced search models |