JP2000057163A

JP2000057163A - 構造化文書データベースシステム

Info

Publication number: JP2000057163A
Application number: JP10227479A
Authority: JP
Inventors: Takuya Kitano; 拓哉北野
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1998-08-12
Filing date: 1998-08-12
Publication date: 2000-02-25

Abstract

(57)【要約】【課題】構造化文書に対する曖昧な条件指定からの文
書要素検索を可能とし、また曖昧な構造条件指定によっ
ても検索性能を劣化させない検索を実現する。【解決手段】構造化文書入力部１によりオブジェクト
指向データベース２に格納された構造化文書に対して、
曖昧な条件指定による文書要素検索を実現すべく、文書
検索式入力部３にてこの曖昧な条件指定を検索式として
表現した入力を受け入れ、文書検索式解析部４でこの条
件式を解析して構造化文書データベース２へアクセスす
るプログラムを組み立てる。文書検索部５でこのプログ
ラムを実際に実行し、プログラムの実行結果として検索
された検索要素を、検索文書表示部６にてシステム外部
へ表示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は構造化文書データベ
ースシステムに関し、特にSGML(Standard Generalized
Markup Language)やXML(eXtensible Markup Language)
などに代表される構造化文書、すなわち文書型定義DTD
(Document Type Definition) と、この文書型定義に従
った文書インスタンスと、この文書インスタンスを構成
する１つ以上の文書要素を持つ構造化文書を格納・管理
して当該構造化文書に対する検索要求に応答して特定の
文書インスタンスまたは文書要素を取り出すことを可能
にするデータベースシステムを構造化文書データベース
システムと呼ぶことにすると、本発明は構造化文書デー
タベースシステムの技術分野に属する。

【０００２】また、整形式(well-formed) のXML 文書と
呼ばれる特定のDTD に従わない文書インスタンスを扱う
構造化文書データベースシステムも本発明の技術分野に
属する。データベースに格納された構造化文書に対する
論理構造及び文書内容の追加・変更・削除の各操作、ま
た論理構造及び文書内容の複数文書間での共有化を可能
にする構造化文書操作部を具備する構造化文書データベ
ースシステムも本発明の技術分野に属するが、構造化文
書操作部の実現方式に関しては本発明の範囲外とする。

【０００３】また全文検索エンジン部と前記全文検索エ
ンジンとが作成する文書インデックスを格納する文書イ
ンデックス格納部とを具備する構造化文書データベース
システムも本発明の技術分野に属するが、全文検索エン
ジン部の実現方式及び文書インデックス格納部の実現方
式に関しては本発明の範囲外とする。また文書インスタ
ンス及び文書要素を表示する検索文書表示部を具備する
構造化文書データベースシステムも本発明の技術分野に
属するが、検索文書表示部の実現方式に関しては本発明
の範囲外とする。

【０００４】

【従来の技術】本発明の管理の対象としている構造化文
書に対して説明する。例として図３、図２０を用いる。
図３は構造化文書の一構成要素である文書型定義(DTD)
の例であり、図２０は構造化文書の一構成要素である文
書インスタンスの例である。文書インスタンスは文書型
定義に基づいて作成される。また文書インスタンスは複
数の文書要素（または単に要素）で構成され、図２０に
示すような木構造を構成する。

【０００５】図３の表記法に関しては、日本ユニテック
SGMLサロン、“はじめてのSGML”、技術評論社、１９９
５、で用いられるDTD の木構造表記法を用いた。四角で
囲った各部分が文書要素を表し、四角の中に文書要素名
を記述する。木構造表記法では一般に最上部に位置する
要素をルート（根）要素と呼び、以下複数の子要素を持
つようなつながりで末端の葉要素まで線（辺、エッジ）
でつなぐ。ある要素の上に位置する要素はその要素の親
要素と呼び、ある要素の下に位置する要素はその要素の
子要素と呼ぶ。

【０００６】図３の四角各以外の記号で丸の中に右矢印
がある記号は、以下の子要素が左から右の順で出現する
という順序出現を表す。要素を表す四角の記号の右上に
添えている＊の記号は、当該要素が０回以上現れること
を表す。特に＊がついていない要素については、当該要
素が１回出現することを表す。

【０００７】図２０は文書型定義で定義した要素の種別
と、出現する親子関係、出現回数の制約を基にして作成
したものである。丸で囲った各部分を文書インスタンス
中の文書要素としてその中に文書要素名を記述する。文
書要素名の後に便宜上英数字を割り振っているが、これ
は他の文書要素と区別するために振ったものであり、基
本的に文書要素名は添字の英数字を除いた部分の文字列
である。ある文書インスタンス中の文書要素の出現順序
に関しては、木構造において左深さ優先順序でならべ、
文書要素の親子関係を線でつないで木構造としている。
図２０の“盲腸”や“胃潰瘍”という文字列に関して
は、それぞれ文書要素「病名１」、「病名２」の中身に
これらの文字列が含まれているということを表してい
る。

【０００８】文書の論理構造に基づく特定の文書要素の
指定とは、図２０を例に説明すると、例えば文書の先頭
から３番目の文書要素とは、最左深さ優先順序で文書要
素「患者」となる。また「カルテ」の２番目の「記録」
の「病名」は、文書要素「病名2 」に含まれる“胃潰
瘍”となる。また１番目の「記録」の2 番目の「患者」
は論理的には存在しないように規制されている。それは
図３の文書型定義で、「記録」に含まれる「患者」はた
だ一つと定義されたからである。このように、文書型定
義の制約に従い、実際の文書インスタンスの文書要素の
木構造の関係を正しく指定すれば、すべての文書要素を
論理的構造に基づいて特定することができる。

【０００９】構造化文書に関する発明としては、構造化
文書データベースシステムに関する発明が過去数件公開
されており、特開平５−２２５２４０号公報では、文書
データベースに蓄積されている構造化文書から一部分の
文書内容を抽出する文書データベース装置に関するもの
である。この発明は上述の「発明の属する分野」で定義
した構造化文書データベースシステムの一部を構成する
基本的な技術である。

【００１０】特開平７−３１９８７４号公報では、デー
タベースから構造化文書を取り出して編集し、また元の
データベースに書き戻す操作に関する技術である。この
技術も構造化文書データベースシステムの一部を構成す
る基本的なものである。特開平９−６７９４号公報で
は、構造化文書の持つ論理構造と管理属性の条件によっ
て特定の構造化文書を検索する装置に関するものであ
り、この技術も構造化文書データベースシステムの一部
を構成する。

【００１１】以上３件の構造化文書データベースシステ
ムの各一部に関する基本的な発明の他に、構造化文書に
対する検索時間の短縮に関する発明、また構造化文書の
論理構造及び文書内容の複数文書間での共有方法に関す
る発明が公開されている。特開平９−６８０３号公報で
は、構造化文書に対する検索式が構造化文書の論理構造
を規定する文書型定義に対して妥当(valid) な検索式で
あるかを事前にチェックし、妥当でない検索式に対して
は検索を行わないようにして検索時間の短縮を図る方式
に関する技術である。この検査式の妥当性のチェック
は、構造化文書の構成を規定する文書型定義で定義され
る各要素に対して、当該要素の子要素及び子孫要素とし
て出現可能な要素の対応表を検索実行前に作成し、当該
対応表を利用して、検索対象の要素が出現不可能である
ような検索式を検出し妥当でないと判断する方式によ
る。

【００１２】特開平９−２９７７６８号公報では、特開
平９−６８０３号公報の検索式の妥当性チェックに用い
る対応表を利用し、入力される検索式の検索条件を満足
する文書構造を生成し得る文書型定義を検出し、文書型
定義に従う構造化文書のみを検索式の検索対象として絞
り込み、検索効率の向上を図る方式に関する技術であ
る。

【００１３】

【発明が解決しようとする課題】第一の課題は、構造化
文書の検索ではしばしば文書の論理構造を指定した検索
がなされるが、１）文書の論理構造が複雑な場合、前記論理構造の条件
指定をユーザが検索式として誤りなく記述するのはユー
ザに負担である；２）その文書の論理構造を誤りなく記述しようとして
も、ユーザが誤りなく文書の論理構造を把握しているか
分からない；３）文書の論理構造は文書型定義によって規定される
が、整形式のXML 文書では文書型定義が含まれない、ま
たは文書型定義に従う必要がないので、XML 文書の文書
型定義から文書の論理構造を調べることは不可能であ
る；４）仮に文書型定義をユーザが入手したとしても、その
文書型定義を読み取って文書の論理構造を把握すること
は困難である；などの問題点がある。

【００１４】よって、本発明では、従来の構造化文書デ
ータベースシステムが提供してきた検索式入力系では、
文書の論理構造を指定した検索はユーザにとって困難な
ものとなっている。ユーザが文書の論理構造の条件指定
に関して、文書型定義に従って厳密に指定しなくても、
ある程度の構造を指定するだけで論理構造に基づく構造
化文書の検索を可能とすることを目的とする。

【００１５】本発明の他の目的である第二の課題は、曖
昧な論理構造指定に関係して、文書内容の条件指定に関
しても曖昧でさまざまな検索条件を指定できるような系
を提供することである。例えば、ある検索キーワード文
字列が特定の文書や文書要素に含まれるかどうかの指定
だけでなく、文字列が当該文書及び文書要素の内容（す
なわち文章である）において、ある閾値を超えた出現頻
度で含まれるかどうかの指定を可能にすることも目的で
ある。

【００１６】現在の文書検索技術では、システムが文書
の意味を解釈して、ある意味に適合する文書のみを取り
出すことは極めて困難である。しかし、例えばキーワー
ド「データベース」がある文書中にある閾値以上の出現
頻度で含まれれば、文書は「データベース」に関する説
明文であるという仮定をおき、その意味で文書の意味の
領域に一歩踏み入れた文書検索を実現させる可能性を持
たせることができる。単純に「データベース」というキ
ーワードが含まれるかどうかだけの条件指定から一段進
み、「データベース」に関する説明文を検索するという
ユーザの意図を極力組み入れる検索方法を提供する。ま
た、文書内容の検索を高速に行うことも本発明の目的で
ある。

【００１７】さらに関連する課題として、一般に全文検
索エンジンによる文書に対するインデックス作成時間
は、ある一定の処理時間を要する。この処理の最中に全
文検索エンジンが停止したりしてインデックス作成が途
中になり、インデックスと文書との関係の一貫性が保持
できなくなったり、また何らかの障害で作成したインデ
ックスが壊れた場合はもう一度作成し直さなければなら
ないなどの問題がある。この問題の解決も本発明の第三
の課題、すなわち目的である。

【００１８】本発明の第四の課題は、第一の課題に関す
る曖昧な論理構造の指定による検索は、厳密に構造を指
定する方法より冗長なオブジェクト間の経路探索（オブ
ジェクトナビゲーション）処理が発生することが予想さ
れる。曖昧な構造指定による検索によっても、極力オブ
ジェクトナビゲーション処理の回数を減らし、検索時間
を短縮することである。

【００１９】

【課題を解決するための手段】本発明によれば、構造化
文書の文書型定義部分をオブジェクトとして格納する文
書型定義格納部と、前記構造化文書の文書インスタンス
部分をオブジェクトとして格納する文書インスタンス格
納部と、前記文書インスタンス（または単に文書）に含
まれる各文書要素（または単に要素）を、そのつながり
関係を保持したままオブジェクトとして格納する文書要
素格納部とを具備したオブジェクト指向データベース
と、前記構造化文書を前記データベースに対して格納制
御する構造化文書入力部と、を含むことを特徴とする構
造化文書データベースシステムが得られる。

【００２０】更に、前記データベースに格納された構造
化文書に対する論理構造及び文書内容の追加・変更・削
除の各操作、また前記論理構造及び文書内容の複数文書
間での共有化を可能にする構造化文書操作部を含み、ま
た、前記データベースに格納された構造化文書に対する
検索を目的とした文書検索式を入力として受け取る文書
検索式入力部と、前記文書検索式を解析し、前記データ
ベースに格納される文書及び文書要素の検索を実行する
文書検索部に対する検索プログラムを組み立て、そして
実行する文書検索解析部とを含むことを特徴とする。

【００２１】さらにはまた、前記データベースに格納さ
れた構造化文書に対する検索を実行し、目的の文書及び
文書要素をオブジェクト指向データベースから取り出す
文書検索実行部を含むことを特徴とし、また前記文書検
索式入力部は、Stanford大学のLorel などに代表される
General Path Expression （オブジェクト参照関係のパ
スやラベルにワイルドカードを含めたり、正規表現を用
いたりする記述）を含む拡張OQL(Object Query Languag
e)を用いて、構造化文書の検索における論理構造や文書
内容の条件に曖昧な指定を可能とする文書検索式が入力
自在であることを特徴とする。

【００２２】更に、前記文書検索解析部が組み立てた検
索プログラムの、前記データベースにおけるオブジェク
トナビゲーションの回数を最小に押さえてその処理時間
を短縮させることを目的とした最適なナビゲーション処
理手順の算出及び検索の目標オブジェクトに直接処理を
移動できるオブジェクト参照関係の作成を行う文書検索
最適化部を含むことを特徴とする。

【００２３】また、前記文書検索式入力部は、前記曖昧
な条件指定を可能とする検索式で、文書内容の条件指定
で単にある文字列が含まれることを条件とする他に、前
記文字列が当該文書内容にある閾値を超えた頻度で含ま
れることを条件とするなどの曖昧な指定を可能とするよ
う構成されており、前記文書検索部に含まれる前記当該
文書内容の文字列検索を高速に行う全文検索エンジン部
と、前記全文検索エンジン部が文書及び文書要素に対し
てあらかじめ作成する文書インデックスを格納する文書
インデックス格納部とを含むことを特徴とし、更に前記
文書検索実行部を含む文書検索部が出力する文書及び文
書要素の論理構造も含めた文書内容の表示を行う検索文
書表示部を含むことを特徴とする。

【００２４】

【発明の実施の形態】以下に本発明の実施の形態につき
図面を参照しつつ説明する。前述した本発明の第一の課
題に対する解決手段としては、まず検索式の論理構造条
件に対する曖昧な記述を可能とする体系を用意すること
である。図１は本発明の実施の形態の概略ブロック図で
ある。

【００２５】本発明では、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 （オブジェ
クト参照関係のパスやオブジェクトのメンバを表すラベ
ルにワイルドカードを含めたり、正規表現を用いたりす
る記述）を検索式に含めることのできる記述体系を文書
検索式入力部３で用意する。

【００２６】一方、オブジェクト指向データベース２に
対して実際に検索を実行する文書検索部５はデータベー
スクラスのメソッドあるいは一般の関数として実装さ
れ、モジュールとして提供される。モジュールはオブジ
ェクト指向データベース２に対する様々な検索機能を実
現し、外部の環境にAPI(Application Program Interfac
e)として公開する。

【００２７】文書検索式入力部３で用意する拡張OQL の
記述体系と、文書検索部５が用意する検索モジュールを
呼び出すためのAPI とでは、記述体系が異なる。一般に
は一つの拡張OQL による検索式を実行するためには、複
数の検索モジュールを手続き的に呼び出す必要がある。
この拡張OQL による検索式に基づいて実行すべき検索モ
ジュールの順序を組み立てる部分が文書検索式解析部４
である。そして実際の検索モジュールの実行を行うのが
文書検索部５である。

【００２８】検索結果として返される構造化文書を表示
する手段として、検索文書表示部６を用意する。この検
索文書表示部６は通常のテキスト表示ブラウザ／エディ
タ、HTML文書を表示するWWW ブラウザ、SGML文書やXML
文書を表示する専用ブラウザなど、本発明ではどれを選
んでも良い。

【００２９】以上の文書検索式入力部３、文書検索式解
析部４、文書検索部５、検索文書表示部６の連携手順の
フローチャートを図２に示す。検索式が入力されるステ
ップ１１は、本システムのユーザが文書検索入力部３に
検索式を入力するステップである。システムは文書検索
式解析部４で検索式の文法チェック（ステップ１２）を
行い、誤りがあればユーザにその誤り個所を提示し、ユ
ーザは検索式を修正し（ステップ１３）、再度検索式を
入力する（ステップ１１）。ステップ１２は一般にパー
ズ(parse) と呼ばれる処理である。

【００３０】文書検索式解析部４のパーズ処理により検
索文が正しいと判断されれば、その検索文の実行に相当
する文書検索部５の各検索モジュールを実行すべく、検
索モジュールの実行順序を決定する（ステップ１４）。
このステップ１４は一般に最適化と呼ばれる処理であ
る。また検索モジュールとは、文書検索部５を構成する
ものであり、オブジェクト指向データベース２に対する
検索処理を行う。

【００３１】各検索モジュールはステップ１４の最適化
によってならべられた順序に従って、手続き的に実行さ
れる（ステップ１５）。そしてオブジェクト指向データ
ベース２から検索の結果として構造化文書が取出される
（ステップ１６）。文書検索部５は前記結果の構造化文
書を検索文書表示部６に渡し、検索表示部６は構造化文
書を表示し（ステップ１７）、ユーザは検索結果内容を
閲覧することができる。

【００３２】曖昧な論理構造指定を可能にする検索式の
記述方法について説明する。基本的には、OQL の文法体
系に、Lorel などで用いられるGeneral Path Expressio
n の使用を許した検索式の記述となる。またこの検索式
の記述方法に関して、本発明でもまた独自の拡張を行っ
ている。本発明の拡張も含めて、その記述方法について
説明する。

【００３３】構造化文書の論理構造の指定は、図４の文
書インスタンスを例にとると、「カルテ」の一番目の
「記録」の一番目の「病名」の一番目の「原因」という
ように厳密に指定する必要がある。しかし、前述の第一
の課題で述べた通り、文書構造が複雑になればなるほど
その論理構造の指定は難しく誤りも多くなりまた不便で
ある。そこでLorel などではワイルドカードを用いて厳
密な論理構造に指定に曖昧性を持たせた記述方式を提案
している。

【００３４】そのワイルドカードは木構造上の(Lorelで
はグラフ構造上の) 任意のオブジェクトパスにマッチす
る‘＃’、各要素の任意の属性値または内容（Lorel で
はノード上のラベルの値）にマッチする‘％’である。
図４の例で、「カルテ．＃．病名．％」と指定すれば、
カルテから辿ることのできる病名の中の任意の属性値ま
たは中身を指定することになり、“盲腸”と“胃潰瘍”
がこれに相当する。

【００３５】ここで特徴的なことは、ワイルドカードの
指定によりカルテと病名の間の「記録」の指定を省略し
たことである。カルテの中のどこかに病名が存在するこ
とが既に分かっているユーザにとっては、論理構造指定
の簡略化を可能にしたことになる。また厳密な論理構造
指定に伴う誤りの機会を減らしたことにもなる。またカ
ルテの中に病名が存在すること自体は分かっていても、
その場所を厳密に指定することができないユーザにとっ
ては、その論理構造指定の難しさを緩和したことにな
る。

【００３６】さらに、図５に示すような図の文書型定義
でない別の文書型定義に従った文書インスタンスがあっ
たときも、ワイルドカードを用いた論理構造指定は有効
である。カルテと病名の間の論理構造である「記録．経
過記録．疾患履歴」はワイルドカード＃によって吸収さ
れ、結果として指定される値は図４の文書インスタンス
の場合と同様に“盲腸”と“胃潰瘍”となる。場合によ
って文書型定義の違いを吸収し、論理構造の指定方法を
変えずに同じように適用できる文書論理構造指定方法と
なっている。

【００３７】ワイルドカード％の効用について述べる。
一般に要素は０以上の属性を持ち、それぞれに値が設定
される。また要素はその要素名を持つタグによって囲ん
だ文書内容（中身）も含んでいる。もし、図４に示した
ように要素「病名１」に含まれる文字列“盲腸”が、例
えば属性「主要病名」の値であることが分かっている場
合は、論理構造指定において、「病名．主要病名」と指
定すれば目的の文字列“盲腸”の格納位置を指定でき
る。

【００３８】しかし、主要病名に含まれいるかどうか分
からない、また主要病名ではなく、例えば属性「疑い病
名」に含まれているかどうか判断がつかない場合は、ワ
イルドカード％を用いて「病名、％病名」と属性名の部
分一致を用いたり、またはすべての属性値または内容
（中身）とマッチする「病名．％」と指定したりして、
目的の“盲腸”の格納位置を指定できる。

【００３９】実際の検索式の記述方法について説明す
る。検索式はOQL やSQL と同様に基本的にselect、fro
m、where の各句で構成される。図４の文書インスタン
スを例に説明する。病名“盲腸”の原因を調べなさい」
という検索要求を記述する検索式は、例えば図６のよう
に記述することが可能である。from句から説明すると、
キーワードrootは本発明で導入するキーワードである
が、対象とする構造化文書のルート要素を示す。図４の
例では、要素「カルテ」となる。「root．＃．病名Ｄ」
で、カルテから辿ることのできる要素「病名」の集合を
Ｄと置いている。さらに「Ｄ．＃．原因」で、Ｄからた
どることのできる「原因」の集合をＣとおいている。

【００４０】where 句では、ある検索条件を示してお
り、要素Ｄの任意の属性値または内容（中身）に“盲
腸”という文字列が含まれているかどうかをチェック
し、その条件を満たす要素Ｄの集合を限定している。li
keは要素Ｄのオブジェクトメンバから呼び出すメソッド
である。ワイルドカード％によって要素Ｄのオブジェク
トの何かしらのメンバとマッチし、そのメンバからメソ
ッドlikeが呼び出されている。今回の例では、要素Ｄの
中身はオブジェクトメンバcontentsに格納しているとし
て、オブジェクトcontentsの中身の文書に対して全文検
索による文字列検索を行うメソッドlikeとして用いてい
る。よって、要素の中身に“盲腸”という文字列を含ん
でいる要素集合Ｄを特定している。

【００４１】select句では、検索結果として取出す要素
を指定している。where 句で制限された要素Ｄから辿る
ことのできる要素「原因」を結果として取出すことを指
定している。この検索に関して曖昧指定を許さない厳密
な指定を行うとすれば図７のような検索式となる。図７
の検索式と比較して図６の検索式における曖昧性指定個
所をまとめると、以下が挙げられる。１）ルート要素が何かを指定していない；２）ルート要素から病名を辿り、さらに病名から原因を
たどることは指定したが、その途中に関する論理構造に
関しては指定していない；３）病名の内容（中身）がオブジェクトメンバとしてど
こに格納されているかを指定せず、ただメソッドlikeを
呼び出すことのできるオブジェクトメンバとしてのみ指
定している。

【００４２】ワイルドカード＃を用いる際の問題点につ
いて述べる。図８の検索式を図４の文書インスタンスに
適用する例でその問題点を示す。図８の検索式では、fr
om句の「root．＃．病名」で指定する要素「病名」を、
where 句の条件指定で要素「病名１」を特定している。
しかし、目的として取出す要素は、「root．＃．原因」
と指定されているため、要素「原因１」と「原因２」と
が取出されてしまう。すなわち、最初の「病名１」を特
定して「病名２」を排除する条件指定をしても、「roo
t．＃．原因」のワイルドカード＃によって要素「原
因」までのすべての経路がマッチしてしまうために、こ
のような結果となる。

【００４３】この問題を解決すべく、本発明ではワイル
ドカード＃の経路に関して制限を加える方法とその記述
方法を検索式に導入する。この記述方法に関しては、Lo
relなどで述べている経路指定子‘＠’の後にその経路
を表す変数を与え、where 句で前記変数を用いて経路に
関して条件を加える方法を採用する。本発明では、この
経路指定子‘＠’を用いてワイルドカード＃の経路を限
定する5 種類の方法について述べる。

【００４４】１種類目の限定方法の例を図９に示し、そ
の限定の手順のフローチャートを図１０に示す。図９で
は、from句で「root．＃＠ｐ．病名」とおき、rootから
病名まで辿ることのできるすべての経路＃を変数ｐで置
き換えている。そしてwhere句で、「ｐ．case＝１」と
指定している。この記法に関しては本発明独自のOQLに
対する拡張である。ワイルドカード＃の経路を表す変数
ｐもオブジェクトとして捉えており、そのメンバ変数ca
seを設定して、指定方法を１としている。本発明ではこ
の表記方法が重要なのではなく、どのような表記方法を
採用するかは、OQL やSQL を拡張するユーザに任され
る。本発明の範囲は、以下で述べるワイルドカード＃の
限定方法が５種類存在することと、その指定ごとの検索
時における処理方法である。

【００４５】図１０のフローチャート内での用語、起点
要素、目標要素とは、ルート要素から辿ることのできる
要素Ａ，Ｂに関して「Ａ．＃．Ｂ」と指定されたときの
Ａが起点要素、Ｂが目標要素ということである。また検
索木とは、データベース内に実際に格納されている木構
造を持つ文書インスタンスをシステムのメモリ上にロー
ドして、検索時のみに利用される一時的なデータ格納構
造である。よって、検索木上の様々な追加・削除・変更
操作は、データベース内のデータの追加・削除・変更と
は異なる。検索木上のデータ操作をデータベースに反映
させるためには、別の手順、例えばデータベースを書き
込み専用としてオープンし、トランザクションのコミッ
ト操作によってメモリ上のデータをデータベースに反映
させる必要がある。しかし、本手順では、データベース
のオープンは検索を目的とした読み込み専用として利用
するので、検索木上でのデータ変更は、データベースに
は反映されない。

【００４６】ステップ２１で、ルート要素から辿ること
のできるすべての起点要素を探索する。そうして見つか
ったすべての起点要素に対して、ステップ２２以下ステ
ップ２２´までのループ処理を行う。ステップ２３で
は、「起点要素．＃．目標要素」を評価する。ステップ
２４では、評価されたすべての目標要素に対してステッ
プ２４以下ステップ２４´までのループ処理を行う。ス
テップ２５では、目標要素に対する条件指定を行ってい
るwhere 句を評価する。そして、条件に満たなかった目
標要素のみに、ステップ２６で除外フラグというあるフ
ラグを立てる。そしてすべての目標要素を評価し終えた
ら、ステップ２７で、除外フラグが立っている目標要素
をすべて検索木から除外する。

【００４７】この一連の操作により、図９の検索式「ro
ot．＃＠ｐ．病名」のルートから辿ることのできる要素
「病名」のうち、図４の要素「病名２」が除外されるこ
ととなる。検索木における要素の探索では、ルート要素
以外はすべて親要素が存在しなければ探索されない。よ
って「病名２」以下の要素「患者ｂ」と「原因２」も、
親要素「病名２」を失うことによって事実上検索木から
除外されることとなる。以上の操作により、図９の検索
式の実行結果は、図４の要素「原因１」が返されること
となる。

【００４８】２種類目の限定方法とその手順について説
明する。その前にまず、前述の限定法法が必要な場合を
示す。図４の文書インスタンスに対して、図１１の検索
式を適用する。図１１の検索式の意図は、「“盲腸”で
ある患者以外の患者の情報を取得せよ」であるとする。
図１１の検索式では、from句の「root．＃．病名」で指
定する要素「病名」をwhere 句の条件指定で、“盲腸”
という文字列を含まない要素を特定するメンバ関数not
likeによって、要素「病名２」を特定している。目的と
して取出す要素は、「root．＃．患者」と指定されてい
る。

【００４９】検索の結果は、病名に関する条件指定とは
関係なく、「患者１」、「患者２」、「患者３」が取出
される。すなわち、最初の「病名２」を特定して「病名
１」を排除する条件指定をしても、「root．＃．患者」
のワイルドカード＃によって要素「患者」までのすべて
の経路がマッチしてしまうために、このような結果が起
ってしまうのである。

【００５０】この問題を解決すべく、２種類目の限定方
法を導入する。この２種類目の限定方法の例を図１２に
示し、その限定の手順のフローチャートを図１３に示
す。ステップ３１からステップ３５までは、限定方法１
のステップ２１からステップ２５まで同様である。異な
るステップは、条件を満たさない当該目標要素に対して
は、ステップ３６ａでその目標要素から当該起点要素ま
でのすべての要素に除外フラグを付けること、条件を満
たす当該目標要素に対しては、ステップ３６ｂで逆にキ
ープフラグを付けることである。そして、ステップ３７
で、除該フラグしか付いていない要素をすべて検索木か
ら除外する。除外フラグとキープフラグの２つが付いて
いる要素に関しては除外しない。

【００５１】この一連の操作により、図１２の検索式
「root．＃＠ｑ．病名」のルートからたどることのでき
る要素「病名」のうち、図４の要素「病名１」のみが除
外され、かつ「病名１」から起点要素「カルテ」におけ
るすべての要素、すなわち図４の場合は要素「記録１」
が除外されることになる。さらに「記録１」の除外に伴
い、以下の要素「患者１」も親要素を失うことによって
事実上検索木から除外される。以上の操作により図１２
の検索式の実行結果は、図４の要素「患者２」と「患者
３」とが返されることとなる。すなわちこれらの患者
は、「“盲腸”である患者以外の患者」である。

【００５２】３種類目の限定方法とその手順について説
明する。その前にまず、この３種類目の限定方法が必要
な場合を示す。図４の文書インスタンスに対して、図１
４の検索式を適用する。図１４の検索式の意図は、
「“盲腸”である患者の患者の情報を取得せよ」である
とする。図１４の検索式では、from句の「root．＃．病
名」で指定する要素「病名」をwhere 句の条件指定で、
“盲腸”という文字列を含む要素「病名１」を特定して
いる。目的として取出す要素は、「root．＃．患者」と
指定されている。

【００５３】検索の結果は、病名に関する条件指定とは
関係なく、「患者１」、「患者２」、「患者３」が取出
される。すなわち、２種類目の限定方法の問題点で述べ
たときと同様に、最初の「病名１」を特定して「病名
２」を排除する条件指定をしても、「root．＃．患者」
のワイルドカード＃によって要素「患者」までのすべて
の経路がマッチしてしまうために、このような結果が起
こってしまうのである。

【００５４】この問題を解決すべく、３種類目の限定方
法を導入する。この３種類目の限定方法の例を図１５に
示し、その限定の手順のフローチャートを図１６に示
す。ステップ４１でルート要素から起点要素を探索し、
そのすべての起点要素に対してステップ４２以下ステッ
プ４２´までのループ処理を行う。ステップ４３では、
文書型定義格納部２ａに格納される文書型定義(DTD) の
情報を基に子要素に目標要素を持ち得る要素を探索す
る。図３のDTD の例を用いると、要素「カルテ」は要素
「健康保険」と要素「記録」を子要素に持ち得る。同様
に、要素「健康保険」は要素「患者」と要素「保険種
別」を持ち得る。

【００５５】このようにDTD の情報を参照することによ
って、ステップ４３で子要素に目標要素を持ち得る要素
の集合が得られる。ステップ４４ではステップ４３で求
まったすべての要素に対してステップ４４以下ステップ
４４´までのループ処理を行う。ステップ４５で、実際
に子要素に目標要素が存在するかチェックする。当該要
素の子要素に目標要素が存在しなければ、ステップ４８
ｂでその要素から当該起点要素までのすべての要素に場
外フラグを付ける。

【００５６】目標要素が子要素として存在すれば、その
目標要素すべてに対して条件を満たすかステップ４７で
判定する。この判定の結果、条件を満たさなければ、ス
テップ４８ａでその目標要素から当該起点要素までのす
べての要素に除外フラグを付ける。条件を満たせばステ
ップ４８ｂでその目標要素から当該起点要素までのすべ
ての要素にキープフラグを付ける。そうして該当する要
素にフラグを付け終わったら、ステップ４９で除該フラ
グしか付いていない要素をすべて検索木から除外する。
除外フラグとキープフラグの２つが付いている要素に関
しては除外しない。

【００５７】この一連の操作により、図１５の検索式
「root．＃＠ｑ．病名」のルートからたどることのでき
る要素「病名」のうち、図４の要素「病名２」が除外さ
れ、かつ「病名２」から起点要素「カルテ」におけるす
べての要素、すなわち図４の場合は要素「記録２」が除
外される。また、要素「病名」を持ち得る要素「記録
３」も、子要素に“盲腸”を含む病名を持たなかったこ
とにより、これも除外される。以上の操作により、図１
５の検索式の実行結果は、図４の要素「患者１」のみが
返されることとなる。すなわちこれらの患者は、「“盲
腸”である患者」である。２種類目の限定方法の違い
は、まさに患者３が結果に含まれるかどうかということ
である。

【００５８】４種類目の限定方法とその手順について説
明する。その前にまず、この限定法が必要な場合を示
す。図１７の文書インスタンスに対して、図１５の検索
式を適用する。図１５の検索式の意図は、「“盲腸”で
ある患者の情報を取得せよ」であるとする。図１５の検
索式を実行すると、前述の３種類目の限定方法でも説明
した通りの手順で、図１７の要素「患者１」が取出され
る。しかし、３種類目の限定方法では、子要素に病名を
持ち得る要素の除外をすることは可能であるが、図１６
の左側にある要素「保険要素」を除外するような指定は
されない。よって、図１７の文書インスタンスに図１５
の検索式を適用すると、「患者１」だけでなく、左側の
「患者」までもが取出されることになる。

【００５９】この問題を解決すべく、４種類目の限定方
法を導入する。この４種類目の限定方法の例を図１８に
示し、その限定の手順のフローチャートを図１９に示
す。ステップ５１からステップ５５までは、限定方法１
のステップ２１からステップ２５まで同様である。異な
るステップは、条件を満たさない当該目標要素に対して
は、ステップ５８でその目標要素に除外フラグを付ける
こと、条件を満たす当該目標要素に対しては、ステップ
５６で、その目標要素から当該起点要素までのすべての
要素にキープフラグを付け、さらにステップ５７で、当
該起点要素を除いてキープフラグの付いたすべての要素
から末端の葉要素に至るすべての要素にキープフラグを
つけることである。そしてステップ５９で、除該フラグ
しか付いていない要素をすべて検索木から除外する。除
外フラグとキープフラグの２つが付いている要素に関し
ては除外しない。

【００６０】この一連の操作により、図１８の検索式
「root．＃＠ｑ．病名」のルートからたどることのでき
る要素「病名」のうち、図１７の要素「病名２」が除外
され、かつ「病名２」から起点要素「カルテ」における
要素「記録２」も除外される。要素「病名」を持ち得る
要素「記録３」も、子要素に“盲腸”を含む病名を持た
なかったことにより、これも除外される。また要素「健
康保険」以下の要素も、“盲腸”を文字列に含む要素
「病名」を持たないとして、除外される。以上の操作に
より、図１８の検索式の実行結果は図１７の要素「患者
１」が返されることとなる。すなわちこれらの患者は、
「“盲腸”である患者の情報であり、健康保険の患者の
情報ではない」ということになる。

【００６１】５種類目の限定方法とその手順について説
明する。その前にまず、この限定法法が必要な場合を示
す。図２０の文書インスタンスに対して、図１８の検索
式を適用する。図１８の検索式の意図は、「病名“盲
腸”にかかった最初の患者の情報を取得せよ」ととし、
すなわち要素「病名」の子要素の「患者」を取得するこ
とを目的とする。図１８の検索式を実行すると、図２０
の要素「病名１」が特定され、要素「患者ａ」と要素
「患者１」が取出される。

【００６２】しかし、「患者ａ」と「患者１」はたまた
ま要素名が同じであるだけで、その意味が異なってい
る。「患者ａ」は「病名１」に関する一つの情報であ
り、ここで述べている検索式ではこの「患者ａ」のみを
取出すことが目的であった。この目的を果たすべく、５
種類目の限定方法を導入する。この５種類目の限定方法
の例を図２１に示し、その限定の手順のフローチャート
を図２２に示す。

【００６３】ステップ６１からステップ６６及びステッ
プ６８までは、限定方法４のステップ５１から５６及び
５８までと同様である。異なるステップは、ステップ６
６のあとステップ６７で目標要素から末端の葉にいたる
までのすべての要素にキープフラグを付けること、該当
するすべての要素にフラグを付けたあと、ステップ６９
でキープフラグのみ付いている要素以外をすべて検索木
から除外することである。除外フラグとキープフラグの
２つが付いている要素に関しては、除外することとな
る。

【００６４】この一連の操作により、図２１の検索式
「root．＃＠ｑ．病名」のルートからたどることのでき
る要素「病名」のうち、図２０の要素「病名２」が除外
され、かつ「病名２」から起点要素「カルテ」における
要素「記録２」も除外される。要素「病名」を持ち得る
要素「記録３」も、子要素に“盲腸”を含む病名を持た
なかったことにより、これも除外される。また要素「記
録３」も、また要素「健康保険」以下の要素も、“盲
腸”を文字列に含む要素「病名」を持たないとして、除
外される。さらに図２２の５種類目の限定方法の操作に
より、「患者１」も除外される。これは、where 句で特
定された要素「病名１」と直接祖先／子孫関係になって
いないからである。以上の操作により、図２１の検索式
の実行結果は、図２０の要素「患者ａ」が返されること
となる。

【００６５】本発明の以上の動作により、オブジェクト
指向データベース２に格納される構造化文書に対する曖
昧な論理構造指定による検索式の記述と実行が可能とな
り、課題を解決する。

【００６６】第二の課題に対する解決手段は、文書に対
する検索のためのインデックスを作成して、文書中の文
字列検索を高速に行う全文検索エンジン部５ｃを文書検
索部５に組み込むことである。前述の第二の課題でも述
べたような、検索キーワードが当該文書中にある閾値以
上の出現頻度で含まれるかどうかの判断が可能かどうか
は、全文検索エンジン部５ｃに用いる全文検索エンジン
の機能次第である。本発明では、通常の文書に対してイ
ンデックスを生成しないで文書の先頭から当該検索キー
ワードを探す文字列検索方式ではなく、インデックスを
文書に対して事前に生成して、長大な文書に対しても高
速に文字列検索が行える全文検索エンジン、またその際
に前記の出現頻度を考慮したような判定方法など様々な
判定方法で文字列検索が行える全文検索エンジンを全文
検索エンジン部5cとして組み込むことを解決の手段とす
る。

【００６７】また、文書インスタンスや文書要素とイン
デックスとの一貫性保持の問題や、障害対策の問題に対
しては、インデックスをオブジェクト指向データベース
２中のインデックス格納部２ｄに格納することにより、
オブジェクト指向データベース２の持つトランザクショ
ン管理、バックアップリカバリの機能を用いて、一貫性
保持の問題、障害対策の問題などを解決する。

【００６８】第三の課題に対する解決手段は、まずオブ
ジェクト指向データベース２に構造化文書を格納する際
に、文書型定義格納部２ａ、文書インスタンス格納部２
ｂ、文書要素格納部２ｃに分けて格納する。一つの構造
化文書に対して、文書型定義が存在すれば最低一つの文
書型定義のオブジェクトと、最低一つの文書インスタン
スのオブジェクトと、そして文書インスタンス中の文書
要素を分解して、文書要素のつながり関係を保持した複
数の文書要素のオブジェクトとが、オブジェクト指向デ
ータベース２には格納されることになる。

【００６９】文書型定義オブジェクトや文書インスタン
スオブジェクトの検索はそれぞれ文書型定義格納部２
ａ、文書インスタンス格納部２ｂ配下の集合から目的の
オブジェクトを取り出す処理となる。文書要素オブジェ
クトに対する検索は、文書インスタンスオブジェクトが
特定された後、文書インスタンスのルート要素となる文
書要素オブジェクトから以下子供の文書要素へと木構造
を辿りながら目的の文書要素オブジェクトを取り出す処
理となる。

【００７０】ここで課題となるのは、文書の論理構造の
指定を明確に指定する検索式しか受け入れないのなら
ば、文書要素オブジェクトのナビゲーション処理で、明
確に指定された論理構造間のみをナビゲートするだけで
目的の文書要素オブジェクトへと辿り着くことができ
る。しかし、例えば、General Path Expression の表記
法の一つで、任意のオブジェクト間のパスにマッチする
ワイルドカード＃を用いて曖昧な論理構造指定を許す
と、その＃で指定したすべてのオブジェクト間のパスを
探索しなければならなくなる。よって、曖昧な論理構造
の指定による検索は、厳密に構造を指定する方法より検
索時間が多くかかることが予想される。

【００７１】このような課題を解決するために、文書型
定義格納部２ａに格納されている、検索対象となってい
る文書インスタンスと関係する文書型定義オブジェクト
の情報と照合し、オブジェクト間の経路探索における不
必要なパスを算出することによって極力オブジェクトナ
ビゲーション処理の回数を減らすことによって課題を解
決する。

【００７２】

【実施例】本発明で扱う構造化文書は文書型定義(DTD)
と、前記文書型定義に従った文書インスタンスを持つ構
造化文書である。ただし、特に文書型定義がなくても文
書インスタンスのみの構造化文書も取り扱うものとす
る。構造化文書を本発明のシステムに登録する手順のフ
ローチャートを図２３に示す。ステップ７１で、構造化
文書入力部１から構造化文書が入力される。構造化文書
入力部１は、ステップ７２で構造化文書中に文書型定義
が存在するか確認し、存在すれば、ステップ７３で文書
型定義を文書型定義格納部２ａに格納する。

【００７３】また、構造化文書入力部１は、ステップ７
４で文書インスタンスを文書インスタンス格納部２ｂに
格納する。さらに、ステップ７５で文書インスタンスの
中身である文書の部分に対して全部検索用のインデック
スを作成し、そのインデックスをインデックス格納部２
ｄに格納する。

【００７４】インデックスの作成に関しては、全文検索
エンジン部５ｃによって作成されるものであるが、その
作成方法に関しては本発明の範囲外である。インデック
スをオブジェクト指向データベースに格納する手段を有
することが本発明の範囲である。構造化文書入力部１は
ステップ７６で文書インスタンスを文書要素毎に分解
し、ステップ７７で文書インスタンス中の文書要素間の
木構造関係を保持したまま、それぞれの文書要素を一つ
のオブジェクトとして文書要素格納部２ｃに格納する。

【００７５】また各文書要素の中身、すなわち各文書要
素のタグで囲まれた文書の部分に対して全部検索用のイ
ンデックスを作成し、そのインデックスをインデックス
格納部２ｄに格納する。文書型定義格納部２ａ、文書イ
ンスタンス格納部２ｂ、文書要素格納部２ｃに実際に格
納されるオブジェクトは、文書型定義格納部２ａなら、
例えば図３の文書型定義全体、文書インスタンス格納部
２ｂなら、例えば図２０の文書インスタンス全体、文書
要素格納部２ｃなら、例えば図２０の各文書要素とその
つながり関係である。

【００７６】以上の構造化文書のインデックスに関する
格納方法は、本発明の第二の課題でも述べた全文検索エ
ンジンが作成するインデックスの保持に関する問題の解
決策となっている。構造化文書の格納では、オブジェク
ト指向データベース２のトランザクション管理によっ
て、一貫性を保持した格納が可能となる。また、文書イ
ンスタンスや文書要素とインデックスはそれぞれオブジ
ェクトとして管理され、その関係はオブジェクト間のリ
ンクとしてオブジェクト指向データベース２によって管
理される。

【００７７】本発明第一の課題に関する発明の実施例に
ついては、第一の課題を解決する手段でも述べたが、本
発明第二の課題と合わせて述べる。図３、図２０に示す
文書型定義と文書インスタンス／文書要素を持つ構造化
文書を例題として取り上げる。この図３、図２０で表現
される構造化文書に対して、図２４に示す拡張OQL によ
る検索式を適用することを考える。この図２４の検索式
の意味を自然言語で述べると、「ルート要素からたどれ
る要素「病名」において(from root．＃．病名Ｄ）、病
名の中身の文書で“盲腸”という文字列が閾値０．６の
出現頻度で現れることを条件とし（where Ｄ．％．li
ke( “盲腸”，０．６））そのような病名から辿ること
ができる原因（from Ｄ．＃．原因Ｃ）を検索結果とし
て返せ(select Ｃ）。」となる。

【００７８】where 句に現れる引数を２つとるメンバ関
数likeは、文書検索部５が用意する検索モジュールの一
つである。この検索モジュールは、第一引数で指定され
た文字列を当該文書中に第二引数で指定された閾値以上
の頻度で現れるかどうかを調べる。第二引数の閾値以上
で第一引数の文字列が出現すればTRUEを返し、そうでな
ければFALSE を返す。また文字列検索自身は、全文検索
エンジン部５ｃが全文検索の対象とする文書インスタン
スや文書要素の内容である各文書に対してあらかじめ作
成されたインデックスを文書インデックス格納部２ｄか
ら引き出してインデックスを用いて高速に検索を行う。

【００７９】ここで言う高速とは、単純に文章の先頭か
ら文字列マッチによって検索する方法と比較して、イン
デックスを用いた文字列マッチの方が一般的に高速であ
るという意味で用いている。本発明では、この全文検索
エンジン部5cの文字列検索方法については範囲外であ
る。

【００８０】また本発明は、メソッドlikeは文書検索実
行部５ａにあらかじめ用意されており、likeを呼び出す
検索式を用いた検索方式の発明に関するものであり、メ
ソッドlikeの実装方法や、likeの第二引数の０．６の意
味などについては本発明の範囲外である。しかしなが
ら、実施例として０．６の意味の一例を述べると、例え
ば、「句点「。」で区切られる文が１０あったとしたと
き、メソッドlikeの第一引数で指定された文字列が１０
の文の中で７つの文中に用いられた場合、文字列の使用
頻度を表す値を０．７とする。likeの第二引数で指定さ
れた閾値は０．６であるので、likeの返却値はTRUEとな
る。」という意味における検索条件指定が可能というこ
とになる。図２０の文書インスタンスに対して検索式wh
ere Ｄ．％．like（“盲腸”、０．６）によって病名１
が条件を満たした場合、図２４の検索式の結果、図２０
の要素「原因１」が返る。

【００８１】本発明第三の課題に関する発明の実施例に
ついて述べる。図２０の文書インスタンスに対して図２
５の検索式を適用する例を用いて説明する。図２５の検
索式のfrom句で、「root．＃．保険種別」としてselect
句で保険種別を取出そうとしている。ここで、ルート要
素から保険種別を探索するのに、図２０の文書インスタ
ンスのすべての経路を探索する必要はない。

【００８２】図２０の文書インスタンスの文書型定義で
ある図３の文書型定義を格納する文書型定義格納部２ａ
では、前記文書型定義図３に対して図２６で示す手順に
従って、すべての文書要素に対して当該文書要素以下の
子孫要素のリストをあらかじめ保持させる。ただし、ス
テップ８３によって作成される子孫要素リストの要素は
重複を許さないこととする。よって目標要素の検索で
は、この文書型定義格納部２ａの各要素定義に対する子
孫要素リストの情報を参照し、目標要素を子孫要素リス
トに含んでいる要素のみを経路探索して目標要素を検索
する。

【００８３】図３の文書型定義で子孫要素リストを説明
すると、要素「カルテ」の子孫要素は、「健康保険」、
「記録」、「患者」、「保険種別」、「病名」、「原
因」である。要素「健康保険」の子孫要素は、「患
者」、「保険種別」である。要素「記録」の子孫要素
は、「患者」、「病名」、「原因」である。よって、要
素「保険種別」を経路探索するのには、「保険種別」を
子孫要素に含んでいる「カルテ」や「健康保険」を探索
し、「保険種別」を子孫要素に含んでいない「記録」は
探索する必要はないということになる。

【００８４】このような、ある起点要素から目標要素を
探索する際に、経路として通る必要のない要素の集合を
本発明では回避要素集合と呼ぶ。「root．＃．保険種
別」における図２０の文書インスタンスの例では、回避
要素集合は「記録」となる。このような回避要素集合を
求める計算は、文書検索最適化部５ｂが行う。文書検索
実行部５ａは回避要素集合の情報を文書探索最適化部５
ｂから取得して、実際の図２０における「保険種別」の
検索において「カルテ．記録．＃」という経路の探索を
一切行わない。

【００８５】以上の回避集合を求めて最適の経路探索を
求める方法は、構造化文書に文書型定義が存在し、かつ
構造化文書の文書インスタンスが文書型定義に対して妥
当である場合のみ有効である。XML の整形式のXML 文書
などに代表されるように、文書型定義が存在しない、ま
たは文書型定義に文書インスタンスが従わなくても許さ
れるような構造化文書では前述の回避要素集合を求める
方法は適用できない。そこで本発明ではもう一つの経路
探索最適化方法を示す。

【００８６】図２７の手順に従って、文書要素格納部２
ｃの各要素の中で必要と思われる要素に対し、すべての
子孫要素への参照のリストを保持させる。子孫要素への
参照リストの作成は文書要素の検索を実行する前にあら
かじめ行っておくものとする。要素「カルテ」に対して
図２７の手順を適用した例を図２８に示す。ただし図２
８では通常の木構造における親子関係を表す辺( エッ
ジ) の記述は省略してある。この方法によって文書要素
に直接子孫要素への参照リストを保持させれば、文書検
索実行部５ａは、文書検索最適化部５ｂが求める回避要
素集合の情報を用いることなく、直接「カルテ」から
「保険種別」への探索を実行し、それ以外の経路探索は
「保険種別」へ辿り着かない経路として探索を実行しな
い。

【００８７】このような文書要素に対してすべての子孫
要素への直接的な参照を保持させておく方法は、要素の
数によってその参照リスト作成処理に多くの時間を要す
ることが予想される。また文書要素間の関係が更新され
た場合、更新に関係する文書要素間の参照関係の更新処
理も多く発生し、性能面で問題が発生する。しかしこの
ような問題は検索の前段階であらかじめ前述の処理を行
っておき、実際の検索では当該処理は行わない利用方法
を採用することによって性能問題を回避することは可能
である。

【００８８】以上の回避要素集合による最適経路探索の
方法または直接の子孫要素への参照を持つ方法、または
これらの方法を組み合わせた方法のいずれかにより、ワ
イルドカード＃を持つ文書要素の探索回数を減らし、結
果として経路探索時間を短縮し、本発明の第三の課題を
解決する。

【００８９】

【発明の効果】本発明により、構造化文書の検索におい
て、論理構造の曖昧な指定による検索を実現した。この
実現の効果は１）必要な論理構造を曖昧に指定するだけで、厳密に論
理構造を指定する場合とほぼ同等の検索結果を得ること
ができる。２）文書の論理構造が複雑な場合、ユーザはそのすべて
の論理構造を厳密に把握しなくても良く、ユーザの文書
型定義を把握する負担を軽減する。３）若干の論理構造が異なる文書インスタンスや文書要
素に対しても、検索式にGeneral Path Expression を用
いて同様の検索の意図で検索を実行することができる。
これは特に、検索式を含むアプリケーションプログラム
が存在した時に、アプリケーションプログラムを書き換
えずに異なる論理構造を持つ構造化文書の検索に適用す
ることができることを意味する。

【００９０】また、曖昧な検索において探索すべきパス
を減らしたり、あらかじめ子孫要素への参照を持った
り、また前述の２つの方法を組み合わせたりする方法に
よる検索で、厳密に構造を指定した場合の検索時間に限
りなく近づけることが可能となった。また、あらかじめ
子孫要素への参照を持つ方法では、整形式のXML 文書な
ど文書型定義が含まれない、または文書型定義に従う必
要がない構造化文書に対しても検索時間を短縮する方法
を適用することができる。

【００９１】本発明では、文書インスタンスや文書要素
の内容に対する文字列検索に全文検索エンジン部5cを組
み込むことにより、高速な検索を実現し、かつ検索キー
ワードの出現頻度を考慮した条件指定など様々な検索指
定を提供した。この出現頻度による検索方法は、例えば
ある検索キーワードが頻繁に出現する文書はその検索キ
ーワードに関する説明文であるなど、ある仮定のもと、
文書の意味内容に基づく検索を実現することができる。

【００９２】また全文検索エンジン部が作成する、文書
インスタンスや文書要素のインデックスを、オブジェク
ト指向データベースの中の文書インデックス格納部に格
納して、トランザクション管理、バックアップリカバリ
などを行うことにより、文書とインデックスの間の不整
合を回避し、インデックスによる文書の正しく高速な文
字列検索の実現、また障害などで同じインデックスを２
回以上生成しなければならなくなる事態の発生の回避な
どに役に立つ。

【図面の簡単な説明】

【図１】本発明の実施例のシステム構成図である。

【図２】検索式入力から検索結果表示までの処理手順を
示す図である。

【図３】構造化文書「カルテ」の文書型定義の例を示す
図である。

【図４】構造化文書「カルテ」の文書インスタンスとそ
の文書要素の例を示す図である。

【図５】文書型定義の異なる別の文書インスタンスとそ
の文書要素の例を示す図である。

【図６】本発明に用いる検索式の一例を示す図である。

【図７】厳密に論理構造を指定した検索式の例を示す図
である。

【図８】ワイルドカード＃の使用が問題となる検索式の
例を示す図である。

【図９】ワイルドカード＃の経路を限定する１種類目の
検索式の例を示す図である。

【図１０】ワイルドカード＃の限定方法の一例のフロー
チャートである。

【図１１】本発明に用いる検索式の他の例を示す図であ
る。

【図１２】ワイルドカード＃の経路を限定する２種類目
の検索式の例を示す図である。

【図１３】ワイルドカード＃の限定方法の他の例のフロ
ーチャートである。

【図１４】本発明に用いる検索式の更に他の例を示す図
である。

【図１５】ワイルドカード＃の経路を限定する３種類目
の検索式の例を示す図である。

【図１６】ワイルドカード＃の限定方法の別の例のフロ
ーチャートである。

【図１７】構造化文書「カルテ」の文書インスタンスと
その文書要素の他の例を示す図である。

【図１８】ワイルドカード＃の経路を限定する４種類目
の検索式の例を示す図である。

【図１９】ワイルドカード＃の限定方法の更に別の例の
フローチャートである。

【図２０】構造化文書「カルテ」の文書インスタンスと
その文書要素の更に他の例を示す図である。

【図２１】ワイルドカード＃の経路を限定する５種類目
の検索式の例を示す図である。

【図２２】ワイルドカード＃の限定方法の他の例のフロ
ーチャートである。

【図２３】構造化文書を格納する処理手順を示す図であ
る。

【図２４】本発明に用いる検索式の別の例を示す図であ
る。

【図２５】本発明に用いる検索式の更に別の例を示す図
である。

【図２６】文書型定義格納部の各要素定義における子孫
要素リスト作成手順を示す図である。

【図２７】文書型定義格納部の各要素定義における子孫
要素への参照リスト作成手順を示す図である。

【図２８】子孫要素への参照をすべて保持する文書要素
「カルテ」の例を示す図である。

【符号の説明】

１構造化文書入部２オブジェクト指向データベース２ａ文書型定義格納部２ｂ文書インスタンス格納部２ｃ文書要素格納部２ｄ文書インデックス格納部３文書検索式入部４文書検索式解析部５文書検索部５ａ文書検索実行部５ｂ文書検索最適化部５ｃ全文検索エンシン部６検索文書表示部７構造化文書操作部

Claims

【特許請求の範囲】

【請求項１】構造化文書の文書型定義部分をオブジェ
クトとして格納する文書型定義格納部と、前記構造化文
書の文書インスタンス部分をオブジェクトとして格納す
る文書インスタンス格納部と、前記文書インスタンス
（または単に文書）に含まれる各文書要素（または単に
要素）を、そのつながり関係を保持したままオブジェク
トとして格納する文書要素格納部とを具備したオブジェ
クト指向データベースと、前記構造化文書を前記データベースに対して格納制御す
る構造化文書入力部と、を含むことを特徴とする構造化
文書データベースシステム。
【請求項２】前記データベースに格納された構造化文
書に対する論理構造及び文書内容の追加・変更・削除の
各操作、また前記論理構造及び文書内容の複数文書間で
の共有化を可能にする構造化文書操作部を含むことを特
徴とする請求項１記載の構造化文書データベースシステ
ム。
【請求項３】前記データベースに格納された構造化文
書に対する検索を目的とした文書検索式を入力として受
け取る文書検索式入力部と、前記文書検索式を解析し、
前記データベースに格納される文書及び文書要素の検索
を実行する文書検索部に対する検索プログラムを組み立
て、そして実行する文書検索解析部とを含むことを特徴
とする請求項１または２記載の構造化文書データベース
システム。
【請求項４】前記データベースに格納された構造化文
書に対する検索を実行し、目的の文書及び文書要素をオ
ブジェクト指向データベースから取り出す文書検索実行
部を含むことを特徴とする請求項１〜３いずれか記載の
構造化文書データベースシステム。
【請求項５】前記文書検索式入力部は、Stanford大学
のLorel などに代表されるGeneral Path Expression
（オブジェクト参照関係のパスやラベルにワイルドカー
ドを含めたり、正規表現を用いたりする記述）を含む拡
張OQL(Object Query Language)を用いて、構造化文書の
検索における論理構造や文書内容の条件に曖昧な指定を
可能とする文書検索式が入力自在であることをを特徴と
する請求項３，４いずれか記載の構造化文書データベー
スシステム。
【請求項６】前記文書検索解析部が組み立てた検索プ
ログラムの、前記データベースにおけるオブジェクトナ
ビゲーションの回数を最小に押さえてその処理時間を短
縮させることを目的とした最適なナビゲーション処理手
順の算出及び検索の目標オブジェクトに直接処理を移動
できるオブジェクト参照関係の作成を行う文書検索最適
化部を含むことを特徴とする請求項３〜５いずれか記載
の構造化文書データベースシステム。
【請求項７】前記文書検索式入力部は、前記曖昧な条
件指定を可能とする検索式で、文書内容の条件指定で単
にある文字列が含まれることを条件とする他に、前記文
字列が当該文書内容にある閾値を超えた頻度で含まれる
ことを条件とするなどの曖昧な指定を可能とするよう構
成されており、前記文書検索部に含まれる前記当該文書
内容の文字列検索を高速に行う全文検索エンジン部と、
前記全文検索エンジン部が文書及び文書要素に対してあ
らかじめ作成する文書インデックスを格納する文書イン
デックス格納部とを含むことを特徴とする請求項５記載
の構造化文書データベースシステム。
【請求項８】前記文書検索実行部を含む文書検索部が
出力する文書及び文書要素の論理構造も含めた文書内容
の表示を行う検索文書表示部を含むことを特徴とする請
求項４記載の構造化文書データベースシステム。