(57)【特許請求の範囲】
【請求項１】
複数の構造化文書を格納するデータベースと、
検索キーワードと同一視するための複数の同一視条件を格納する同一視条件情報記憶手段と、
クライアント端末から与えられる検索要求に含まれている検索式が全ての同一視条件を一括して指定するための一括同一視条件を含む場合、前記同一視条件情報記憶手段に格納されている前記複数の同一視条件の全てに基づいて前記検索式に含まれている検索キーワードを展開する同一視展開手段と、
前記検索式に含まれている検索キーワード及び前記展開された検索キーワードに基づいて、前記データベースから前記検索式の示す検索条件に合致する構造を含む構造化文書を検索する検索処理手段と、
前記同一視展開手段が前記同一視条件の各々に基づいて前記検索式に含まれている検索キーワードを展開するに際し、当該同一視条件の各々に固有の文字種の前記データベースに格納されている構造化文書に含まれる文字のうち前記検索式の示す構造に対応する文字の有無に基づき、当該同一視条件の各々での検索でヒットする可能性の有無を判定し、ヒットする可能性の無い同一視条件を除外する同一視条件除外手段とを具備し、
前記同一視展開手段は、前記同一視条件除外手段によって除外された同一視条件を前記検索キーワードの展開の対象外とする
ことを特徴とする構造化文書検索システム。
【請求項２】
予め定められた複数の文字種の各々について、前記データベースに格納されている構造化文書に含まれる当該文字種の文字の有無を示す情報を、当該構造化文書の構造ごとに格納する文字種情報記憶手段を更に具備し、
前記同一視条件除外手段は、前記同一視条件の各々での検索でヒットする可能性の有無を、当該同一視条件の各々に固有の文字種及び前記検索式の示す構造に対応付けて前記文字種情報記憶手段に格納されている文字の有無を示す情報に基づき判定する
ことを特徴とする請求項１記載の構造化文書検索システム。
【請求項３】
前記文字の有無を示す情報が文字数であることを特徴とする請求項２記載の構造化文書検索システム。
【請求項４】
前記文字種情報記憶手段を管理し、前記データベースに構造化文書が格納される際に、当該構造化文書の構造ごとに、当該構造に含まれるテキストを対象に文字種を識別すると共に文字数を計算し、当該識別された文字種及び当該構造化文書の構造に対応付けて前記文字種情報記憶手段に格納されている文字数を前記計算された文字数だけ増加する文字種情報管理手段を更に具備することを特徴とする請求項３記載の構造化文書検索システム。
【請求項５】
複数の構造化文書を格納するデータベース及び検索キーワードと同一視するための複数の同一視条件を格納する同一視条件情報記憶手段を管理すると共に、前記データベースに格納されている構造化文書を対象とする検索処理を行うデータベースサーバコンピュータに、
クライアント端末から与えられる検索要求を受け付けるステップと、
前記受け付けられた検索要求に含まれている検索式が全ての同一視条件を一括して指定するための一括同一視条件を含むかを判定するステップと、
前記検索式が前記一括同一視条件を含む場合、前記同一視条件情報記憶手段から前記複数の同一視条件を全て取得するステップと、
前記取得された同一視条件の各々に固有の文字種の前記データベースに格納されている構造化文書に含まれる文字のうち前記検索式の示す構造に対応する文字の有無に基づき、当該同一視条件の各々での検索でヒットする可能性の有無を判定するステップと、
前記取得された前記複数の同一視条件のうちの前記ヒットする可能性が無いと判定された同一視条件を除く同一視条件に基づいて前記検索式に含まれている検索キーワードを展開するステップと、
前記検索式に含まれている検索キーワード及び前記展開された検索キーワードに基づいて、前記データベースから前記検索式の示す検索条件に合致する構造を含む構造化文書を検索するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースに格納された構造化文書を検索する構造化文書検索システムに係り、特に複数の同一視条件がついた検索に好適な構造化文書検索システム及びプログラムに関する。
【背景技術】
【０００２】
多くのデータベース管理システムは、検索機能の一部として「同一視検索」機能を備えている。同一視検索とは、検索キーワードとそれと同一視する文字種または文字列を指定する検索のことである。よく用いられる同一視条件を以下に例示する。
【０００３】
（１）英数字同一視・・・英数字の大文字及び小文字（これをcaseと表現する）並びに全角（全角文字）及び半角（半角文字）（これをwidthと表現する）を同一視する。
【０００４】
（２）仮名同一視・・・平仮名及び片仮名（これをkanaと表現する）並びに平仮名と片仮名の大文字及び小文字（これをkanacaseと表現する）を同一視する。
【０００５】
（３）異体字同一視・・・仮名や漢字の異体字を同一視する。
【０００６】
（４）同義語同一視・・・同義語を同一視する。
【０００７】
例えば検索キーワードが「あA」である場合、英数字同一視条件を指定すると「あa」「あＡ」「あａ」もヒットする。仮名同一視条件を指定すると「アA」「ぁA」「ァA」もヒットする。複数の同一視条件を同時に指定した場合は、更にヒットする語彙が増える。
【０００８】
このように同一視検索では、検索キーワードと完全に一致する語彙に加えて同一視条件に適合した語彙もヒットする。このため同一視検索は、表記ゆれを考慮した検索などに便利であるが、同一視条件に従って展開（いわゆる同一視展開）した語彙もサーチすることから、検索の処理コストが増加するという問題がある。この問題を、索引情報の工夫により解決する方法が、例えば特許文献１及び２で提案されている。特許文献１は、同一視する検索としない検索とで、使用する索引情報を分けることによって処理コストを抑える方法を提案している。特許文献２は、ハッシュ値を工夫して、同一視される語彙を同じ索引情報として管理することによって処理コストを抑える方法を提案している。
【０００９】
ところで近年は、論理構造を持つ文書（つまり構造化文書）が、データベース管理システムによって管理されるようになってきている。構造化文書において、当該文書の論理構造は、当該文書中に記述されたタグによって示される。このタグを用いて論理構造が表現された構造化文書は、コンピュータでの処理に適している。
【００１０】
さて、タグを用いてデータを記述する手段として、ＸＭＬ（Extensible Markup Language）が広く利用されている。ＸＭＬは、意味付けされたタグによるデータの階層化や構造の自由な拡張性という特長を持つ。これらの特長を生かしたＸＭＬ利用技術として、ＸＭＬデータベース（ＸＭＬＤＢ）と呼ばれるデータベースが知られている。ＸＭＬデータベースはＸＭＬデータベース管理システム（ＸＭＬＤＢＭＳ）と呼ばれるデータベース管理システムによって制御され、ＸＭＬ文書を格納し、またＸＭＬ文書（中の指定された構造）を検索する機能を提供する。このようなデータベース管理システムにおいても、同一視検索を適用して、同一視条件を満たすＸＭＬ文書（構造化文書）を検索することが可能である。
【００１１】
ＸＭＬ文書（内の要素）の検索には標準化された問い合わせ言語がよく利用される。問い合わせ言語の主なものはＸＰａｔｈとＸＱｕｅｒｙである。ＸＰａｔｈは、ＸＭＬ文書中の要素（ノード）の位置を指定して検索を行うのに用いられる。
【特許文献１】特開２００４−１９９２８２号公報
【特許文献２】特開２００６−１０６８９６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
同一視検索では、同一視条件ごとに同一視する／しないを切り替える条件指定が必要な場合もあるが、逆に全ての同一視条件をまとめて同一視する／しないに指定する条件指定が必要な場合もある。Ｗｅｂ検索サービスがその例である。
【００１３】
従来技術では、後者の場合にも複数の同一視条件を個別に指定する必要がある。そのためクエリ（問い合わせ）を記述するのに手間がかかり、またクエリが長くなって意味を解釈するのが難しいという問題がある。また同一視条件を指定するためのクエリ文法を全て知る必要がある。
【００１４】
ＸＱｕｅｒｙを使って具体例を示す。ここでは説明の便宜上、同一視条件として「英数字同一視」と「仮名同一視」の２つだけがあると仮定し、英数字同一視を“case/width (in)sensitive”、仮名同一視を“kana/kanacase (in)sensitive”と記述することにする。
【００１５】
全ての同一視条件を同一視するに指定する場合、クエリ（検索式）は、例えば
/item/name [./text() ftcontains “社員Aさん” case insensitive width insensitive kana insensitive kanacase insensitive]
のようになる。ここで、“ftcontains”はＸＱｕｅｒｙの全文検索演算子を意味するものとする。また、“case insensitive”と“width insensitive”と“kana insensitive”と“kanacase insensitive”とが、同一視条件を指定している部分であり、この４つの同一視条件指定部分によりクエリが長くなっている。
【００１６】
一方、同一視検索では、実際にヒットする／しないに拘わらず、同一視条件の指定通りに検索キーワードが同一視展開される。このため、同時に指定する同一視条件が多いほど展開数が増え、検索の処理コストが増大する。例えば英数字と平仮名とを含む２文字の検索キーワード“あA”の場合、英数字同一視または仮名同一視の単一指定なら展開数は４となる。しかし、英数字同一視と仮名同一視との同時指定なら展開数は１６に増加する。
【００１７】
特許文献１及び２は処理コストを抑える方法を提案している。しかし特許文献１及び２が提案する方法においても、同一視条件に従って検索キーワードが同一視展開される。このため、展開された語彙にヒットしなかった場合には、その展開に要した処理コストが無駄となる。
【００１８】
本発明は上記事情を考慮してなされたものでその目的は、複数の同一視条件が記述されていない検索式であっても、当該検索式に基づいて複数の同一視条件に従う同一視検索を行うことができる構造化文書検索システム及びプログラムを提供することにある。
【課題を解決するための手段】
【００１９】
本発明の１つの観点によれば、複数の構造化文書を格納するデータベースを備えた構造化文書検索システムが提供される。前記構造化文書検索システムは、検索キーワードと同一視するための複数の同一視条件を格納する同一視条件情報記憶手段と、クライアント端末から与えられる検索要求に含まれている検索式を解析し、当該検索式に基づいて前記データベースに格納されている構造化文書を対象とする検索処理を行う検索処理手段と、前記検索式が全ての同一視条件を一括して指定するための一括同一視条件を含む場合、前記同一視条件情報記憶手段に格納されている前記複数の同一視条件の全てに基づいて前記検索式に含まれている検索キーワードを展開する同一視展開手段とを具備する。前記検索処理手段は、前記検索式に含まれている前記検索キーワード及び前記展開された検索キーワードに基づいて、前記データベースから前記検索式の示す検索条件に合致する構造を含む構造化文書を検索する。
【発明の効果】
【００２０】
本発明によれば、検索式に一括同一視条件を含める（記述する）だけで、同一視条件情報記憶手段に格納されている複数の同一視条件の全てが当該検索式に含められているかの如く、当該検索式に基づいて当該複数の同一視条件に従う同一視検索を行うことができる。このため、ユーザにとって検索式の記述が容易になり、また検索式が短くなるので意味を解釈しやすくなるという効果がある。またユーザは、一括同一視条件によって自動的に指定される複数の同一視条件の各々について知らなくても、当該複数の同一視条件の全てを使った検索を構造化文書検索システムに対してクライアント端末から要求することができる。また、一括同一視条件によって自動的に指定される同一視条件が新たに増えても、即ち同一視条件情報記憶手段に新たな同一視条件が追加されても、検索式を変更する必要がない。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の実施の形態につき図面を参照して説明する。  
図１は本発明の一実施形態に係る構造化文書検索システム５０を含むクライアント−サーバシステムのハードウェア構成を示すブロック図である。クライアント−サーバシステムは、主として、データベースサーバ１０と、複数のクライアント端末（クライアント）とから構成される。複数のクライアント端末はクライアント端末２０を含む。クライアント端末２０上では、データベースサーバ１０を利用するアプリケーション（アプリケーションプログラム）が動作する。クライアント端末２０を含む複数のクライアント端末は、ローカルエリアネットワーク（ＬＡＮ）のようなネットワーク３０を介してデータベースサーバ１０と接続されている。
【００２２】
なお、図１では、クライアント端末２０以外のクライアント端末は省略されている。そこで以下では、クライアント端末２０だけが構造化文書検索システム５０を利用するものとして説明するが、他のクライアント端末もクライアント端末２０と同様に構造化文書検索システム５０を利用できることは勿論である。
【００２３】
データベースサーバ１０は、主メモリのようなメモリ１１を有するコンピュータ（データベースサーバコンピュータ）である。データベースサーバ１０は、ハードディスクドライブのような外部記憶装置４０と接続されている。この外部記憶装置４０は、データベース管理プログラム４１及びデータベース４２を格納する。本実施形態において構造化文書検索システム５０は、データベースサーバ１０及び外部記憶装置４０（に格納されているデータベース４２）によって実現される。
【００２４】
データベース管理プログラム４１は、データベースサーバ１０によるデータベース４２の管理、及びクライアント端末２０からの例えばＸＱｕｅｒｙを用いた問い合わせに基づく検索処理に用いられる。データベース４２は構造化文書としての例えばＸＭＬ文書（ＸＭＬ形式の電子文書）を格納するＸＭＬ文書データベース（構造化文書データベース）である。
【００２５】
図２は図１に示される構造化文書検索システム５０の主として機能構成を示すブロック図である。構造化文書検索システム５０は、データベース管理システム５１及びデータベース４２から構成される。データベース４２には、ＸＭＬ文書の集合に加えて、当該データベース４２に格納されているＸＭＬ文書を検索するのに用いられる索引が格納される。
【００２６】
データベース管理システム５１は、要求処理部５２、同一視条件管理部５３、検索処理部５４、索引管理部５５、文書登録部５６及びデータベース操作部５７を含む。  
要求処理部５２は、クライアント端末２０からの要求（コマンド）を受け付けて当該要求の種別を判別し、その判別結果に基づいて当該要求を要求処理部５２、同一視条件管理部５３、検索処理部５４、索引管理部５５または文書登録部５６に送出する入力インタフェースとして機能する。ここでは要求処理部５２は、クライアント端末２０からの要求が同一視条件設定要求（詳細は第２の変形例で述べる）ならば、当該同一視条件設定要求を同一視条件管理部５３に送出し、
検索要求ならば当該検索要求を検索処理部５４に送出する。また要求処理部５２は、クライアント端末２０からの要求が索引設定要求ならば当該索引設定要求を索引管理部５５に送出し、文書登録要求ならば当該文書登録要求を文書登録部５６に送出する。要求処理部５２はまた、クライアント端末２０からの要求に対する同一視条件管理部５３、検索処理部５４、索引管理部５５または文書登録部５６からの応答を当該クライアント端末２０に返す出力インタフェースとしても機能する。
【００２７】
同一視条件管理部５３は、同一視条件、例えば構造化文書検索システム５０（内のデータベース管理システム５１）とクライアント端末２０との間の通信に用いられるセッションごとの同一視条件を管理する。同一視条件管理部５３は同一視条件記憶部５３０を含む。同一視条件情報記憶部５３０は、上述のセッションごとに各同一視条件の適用／非適用（つまり同一視する／しない）を管理するのに用いられる同一視条件情報５３１を格納する。同一視条件情報記憶部５３０は、データベースサーバ１０が有するメモリ１１内の一部の記憶領域を用いて実現されるものとする。同一視条件情報記憶部５３０を、外部記憶装置４０の一部の記憶領域を用いて実現してもよい。
【００２８】
図３は、同一視条件情報５３１の一例を示す。以下では説明の便宜上、同一視条件として「英数字同一視（case/width）」と「仮名同一視（kana/kanacase）」の２つだけがあると仮定する。
【００２９】
本実施形態において同一視条件情報５３１は、図３に示されるように表形式で管理される。同一視条件情報５３１は、列要素（列項目）としてセッション番号と各同一視条件を含む。同一視条件情報５３１は、クライアント端末との通信に用いられるセッション（本実施形態では、接続中のセッション、つまり確立中のセッション）ごとに、当該セッションのセッション番号と、各同一視条件の同一視する／しない（適用／非適用）とを、それぞれ値（表要素の値）として持つ。このセッションごとの、セッション番号と各同一視条件の同一視する／しないを示す値との組からなる情報を、セッション対応同一視条件情報と呼ぶ。
【００３０】
セッションが確立していないとき、当該セッションに固有の同一視条件情報（セッション対応同一視条件情報）は空である。セッションが確立し、その旨が要求処理部５２から同一視条件管理部５３に通知されると、当該同一視条件管理部５３によってそのセッションに関する情報が同一視条件情報５３１中に追加される。ここでは、確立したセッションに固有の同一視条件情報における各同一視条件が“する”（同一視する）に設定される。図３の例では、セッション（セッション番号）によっては、“する”の逆の設定を意味する“しない”（同一視しない）も敢えて記述されているが、本実施形態ではセッションが確立したときに全て“する”に設定される。セッションが切断され、その旨が要求処理部５２から同一視条件管理部５３に通知されると、当該同一視条件管理部５３によってそのセッションに関する情報が削除される。
【００３１】
再び図２を参照すると、検索処理部５４は、クライアント端末２０から送られた検索要求（クエリ）を要求処理部５２を介して受け取り、当該クエリに含まれている検索式に従う検索処理を行う。
【００３２】
索引管理部５５は、検索処理部５４による検索処理に用いられる索引を管理する。索引管理部５５は、文書登録部５６によるＸＭＬ文書の登録時に、当該ＸＭＬ文書に含まれているノード（要素）に対応付けられる索引を作成してデータベース４２に登録する。
【００３３】
文書登録部５６は、クライアント端末２０からの文書登録要求を要求処理部５２を介して受け取り、当該文書登録要求で指定されたＸＭＬ文書をデータベース４２に登録（格納）する文書登録処理を行う。データベース操作部５７は、検索処理部５４、索引管理部５５及び文書登録部５６がデータベース（データベースファイル）４２にアクセスするのを可能とするインタフェースとして機能して、当該データベース４２に対する処理を行う。
【００３４】
本実施形態において、要求処理部５２、同一視条件管理部５３、検索処理部５４、索引管理部５５、文書登録部５６及びデータベース操作部５７は、図１のデータベースサーバ１０が外部記憶装置４０に格納されているデータベース管理プログラム４１を当該サーバ１０内のメモリ１１に読み込んで実行することにより実現されるものとする。このプログラム４１は、コンパクトディスク、或いはＲＯＭのような、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム４１が、ネットワーク３０を介してデータベースサーバ１０にダウンロードされても構わない。
【００３５】
次に、構造化文書検索システム５０の動作について説明する。  
＜文書登録処理＞
まず、構造化文書検索システム５０における文書登録処理について、図４のフローチャートを参照して説明する。
【００３６】
今、ユーザが、データベース４２に登録されるべきＸＭＬ文書を指定して、当該ＸＭＬ文書の登録を指示するための操作を、クライアント端末２０上で行ったものとする。するとクライアント端末２０は、構造化文書検索システム５０に対して、指定のＸＭＬ文書をデータベース４２に登録させるための登録要求（文書登録要求）をネットワーク３０経由で送出する（ステップＳ１）。
【００３７】
要求処理部５２は、クライアント端末２０からの登録要求を受け取ると、当該登録要求を文書登録部５６に渡してＸＭＬ文書（ＸＭＬドキュメント）の登録を要求する（ステップＳ２）。文書登録部５６は、クライアント端末２０からの登録要求を要求処理部５２を介して受け取ると、当該要求で指定されたＸＭＬ文書のパース（構文解析）を開始する（ステップＳ３）。
【００３８】
文書登録部５６は、ＸＭＬ文書のパースによって当該ＸＭＬ文書から要素（ノード）が抽出される都度、そのノードについて次のように処理を行う（ステップＳ４）。  
まず文書登録部５６は、抽出されたノードの情報、例えば抽出されたノードの構造（を表すパス）を含む情報（ノード情報）を索引管理部５５に渡して索引登録処理を行わせる。抽出されたノード（要素）の内容（値）がテキストの場合、当該ノードの内容に対応するノード、つまり当該ノードの直下のノードは、テキストノードと呼ばれる。このように、抽出されたノード（要素）の内容がテキストの場合、ノード情報は、当該ノードの構造（パス）と当該ノードの直下のテキストノードの値とを含む。
【００３９】
索引管理部５５は、文書登録部５６からノード情報を受け取ると、当該ノード情報中の構造（パス）を含む索引を作成して、当該索引をデータベース４２に追加登録する索引登録処理を行う（ステップＳ５）。本実施形態では、ノード情報がテキストノードの値を含む場合、作成される索引は、構造（パス）とテキストノードの値の組を含むものとする。
【００４０】
次に文書登録部５６は、抽出されたノード（つまりＸＭＬ文書の一部）をデータベース４２に格納するドキュメント格納処理を行う（ステップＳ６）。データベース４２内では、当該データベース４２に格納される複数のＸＭＬ文書は、１つの仮想的なＸＭＬ文書の一部の構造をなす部分的な文書として、当該仮想的なＸＭＬ文書のルートノード（／）の下位に位置付けられる。
【００４１】
文書登録部５６は、ドキュメント格納処理（ステップＳ６）を行うと、クライアント端末２０から要求されたＸＭＬ文書のパースが全て終了したか、つまりＸＭＬ文書に含まれている全てのノードについて処理をし終えたかを判定する（ステップＳ７）。もし、未処理のノードが残っているならば（ステップＳ７）、文書登録部５６は上記ステップＳ４に戻り、次のノードについて処理を継続する。これに対し、未処理のノードが残っていないならば、即ち要求されたＸＭＬ文書のパースが全て終了したならば（ステップＳ７）、検索処理部５４は文書登録処理を終了する。
【００４２】
ＸＭＬ文書から抽出されるノードの順序は、当該ＸＭＬ文書に出現するノードの順序に一致する。したがって上述の文書登録処理では、ＸＭＬ文書に出現する順番にノードが処理される。
【００４３】
ここで、クライアント端末２０から登録が要求されたＸＭＬ文書が
<item>
<id>0001</id>
<name>社員Aさん</name>
</item>
であるとする。
【００４４】
図５は、上記ＸＭＬ文書がデータベース４２に登録された場合に作成される索引の例を示す。図５の例では、索引は、登録されるＸＭＬ文書から抽出されたノードの構造（パス）と、（ＸＭＬ文書の木構造上で）その直下のテキストノード値の組を含む。
【００４５】
例えば、<id>ノードに関する索引は、<id>ノード（要素）の構造“/item/id”と、当該<id>ノードの内容であるテキストノードの値“0001”、つまり当該<id>ノードの直下のテキストノードの値“0001”とを含む。同様に、<name>ノードに関する索引は、<name>ノードの構造“/item/name”と、当該<name>ノードの直下のテキストノードの値“社員Aさん”とを含む。但し、<item>ノードのように、直下にテキストノードが存在しないノードに関しては、テキストノードの値に代えて、空文字列を意味する記号“−”が用いられる。
【００４６】
＜検索処理＞
次に、構造化文書検索システム５０における検索処理について、図６のフローチャートを参照して説明する。
【００４７】
今、ユーザがクライアント端末２０を操作することにより、当該クライアント端末２０から構造化文書検索システム５０に対して、現在確立しているセッションを用いて、ネットワーク３０経由で検索要求が送出されたものとする（ステップＳ１１）。この検索要求は検索式を含む。
【００４８】
要求処理部５２は、クライアント端末２０からの検索要求を受け取ると、当該検索要求を検索処理部５４に渡して検索を要求する（ステップＳ１２）。検索処理部５４は、検索要求に含まれている検索式を解析することにより（ステップＳ１３）、当該検索式に「一括同一視条件」が含まれているか、つまり当該検索式で「一括同一視条件」が指定されているかを判定する（ステップＳ１４）。一括同一視条件とは、予め設定されている複数の同一視条件の全てを一括して指定するための検索条件を意味する。本実施形態では、一括同一視条件に文字列“all insensitive”の記述が用いられるものとする。
【００４９】
検索処理部５４は、検索式で一括同一視条件“all insensitive”が指定されているならば（ステップＳ１４）、当該検索式を含む検索要求の送信に用いられたセッションのセッション番号を用いて同一視条件管理部５３に当該セッションの同一視条件情報（セッション対応同一視条件情報）を問い合わせる（ステップＳ１５）。すると同一視条件管理部５３は、同一視条件情報記憶部５３０に格納されている同一視条件情報５３１の中から、検索処理部５４から問い合わせられたセッション番号のセッションに固有の同一視条件情報のみを抽出して、検索処理部５４に返す。これにより検索処理部５４は、上記ステップＳ１５において、目的のセッションに固有の同一視条件情報（セッション対応同一視条件情報）、即ち目的のセッションに対応付けられた全て同一視するに設定された複数の同一視条件を示す情報を取得する。なお、検索処理部５４が同一視条件情報記憶部５３０に格納されている同一視条件情報５３１を直接参照することにより、目的のセッションに固有の同一視条件情報を取得するようにしても構わない。
【００５０】
次に検索処理部５４は、取得した同一視条件情報に従い、解析された検索式によって示される検索条件として個々の同一視条件を設定する（ステップＳ１６）。この同一視条件情報に従う検索条件の設定について、検索式（クエリ）がＸＱｕｅｒｙ式であるものとして具体例を挙げて説明する。
【００５１】
まず、セッション番号１のセッション（以下、セッション＃１と称する）で以下の検索式（クエリ）
/item/name [./text() ftcontains “社員Aさん” all insensitive]
を含む検索要求が実行されるものとする。このとき、同一視条件情報記憶部５３０に格納されている同一視条件情報５３１が図３の状態にあるものとする。
【００５２】
上記クエリでは、一括同一視条件“all insensitive”が指定されている。このため検索処理部５４は、同一視条件管理部５３に問い合わせることで、セッション＃１に固有の同一視条件情報（セッション対応同一視条件情報）を取得する（ステップＳ１５）。
【００５３】
図３から明らかなように、セッション＃１に固有の同一視条件情報は、英数字同一視及び仮名同一視（“kana insensitive”と“kanacase insensitive”）を共に“する”（同一視する）に設定された同一視条件（英数字同一視条件及び仮名同一視条件）を含む。この場合、検索処理部５４は、上記クエリにおける一括同一視条件“all insensitive”が、英数字同一視をする（“case insensitive”及び“width insensitive”）と共に仮名同一視をする（“kana insensitive”及び“kanacase insensitive”）検索条件を表していると判断する。そして検索処理部５４は、上記クエリにおける“all insensitive”を、“case insensitive width insensitive kana insensitive kanacase insensitive”に自動的に置き換える。
【００５４】
これにより上記クエリは、以下のクエリ
/item/name [./text() ftcontains “社員Aさん” case insensitive width insensitive kana insensitive kanacase insensitive]
と同等となる。
【００５５】
このように、検索処理部５４は取得された同一視条件情報に従って、一括同一視条件“all insensitive”に代えて、英数字同一視及び仮名同一視を共にすることをそれぞれ示す、英数字同一視条件（“case insensitive”及び“width insensitive”）及び仮名同一視条件（“kana insensitive”及び“kanacase insensitive”）を設定する（ステップＳ１６）。なお本実施形態では、クエリにより一括同一視条件及び個々の同一視条件の両方が指定されている場合、個々の同一視条件は無視される（エラー扱いとされる）ものとする。
【００５６】
索引管理部５５は、検索処理部５４によってステップＳ１６が実行されると、同一視展開手段として機能して、検索処理部５４によって解析されたクエリ（検索式）に含まれている検索キーワードと当該ステップＳ１６で設定された個々の同一視条件とに従って、当該検索キーワードを展開する（ステップＳ１７）。次に索引管理部５５は索引検索処理手段として機能して、展開後の全ての検索キーワードに対し、データベース４２に格納されている索引を用いて、検索条件に合致するノードのリストを検索結果として取得する（ステップＳ１８）。ここでは、上記クエリ（検索式）により検索対象パスとして“/item/name”が指定されていることから、ステップＳ１８での検索には、パス“/item/name”を含む索引が用いられる。検索処理部５４は、索引管理部５５による索引を用いての検索結果を要求処理部５２によりクライアント端末２０に返す（ステップＳ１９）。
【００５７】
なお、データベース４２に格納されている索引を、構造化文書検索システム５０の起動時にデータベースサーバ１０内のメモリ１１にコピーしておき、索引管理部５５による検索処理にはこのコピーされた索引を用いることにより、検索処理を高速化することも可能である。また、索引管理部５５の同一視展開手段としての機能及び索引検索処理手段としての機能の一方または両方を検索処理部５４に持たせることも可能である。また、同一視展開手段としての機能を、検索処理部５４から独立の手段に持たせることも可能である。
【００５８】
一方、検索要求に含まれている検索式で一括同一視条件が指定されていない場合（ステップＳ１４）、ステップＳ１５及びＳ１６をスキップしてステップＳ１７が実行される。この場合、クライアント端末２０からの検索要求に含まれているクエリで直接指定された同一視条件に従って検索キーワードが展開される。
【００５９】
本実施形態によれば、検索式内に個々の同一視条件を記述する必要がないため、ユーザにとって検索式の記述が容易になり、また検索式が短くなるので意味を解釈しやすくなる。また、ユーザは個々の同一視条件について知らなくても、一括同一視条件を用いるだけで、予め設定されている全ての同一視条件を使った検索を構造化文書検索システム５０に行わせることができる。また本実施形態によれば、一括指定可能な同一視条件が新たに増えても、その新たな条件についても既に設定されている同一視条件と同一視する／しないが同じであれば、検索式を変更する必要がない。
【００６０】
［第１の変形例］
上記実施形態では、クエリに一括同一視条件を設定（記述）することにより、予め設定されている複数の同一視条件の全てを一括して指定することができる。しかし、一括して指定される複数の同一視条件の中に検索に不要な同一視条件が含まれている場合には、一括同一視条件を利用できない。
【００６１】
そこで、一括同一視条件から除外すべき同一視条件を指定可能とする上記実施形態の第１の変形例について説明する。この第１の変形例では、クエリ（検索式）に、一括同一視条件から除外すべき同一視条件、つまり一括同一視指定の対象外とする同一視条件“except XXX”（“XXX”は“case”、“width”など同一視条件を意味する文字列）を記述できるものとする。この一括同一視条件の対象外とする同一視条件を同一視除外条件と称する。
【００６２】
＜検索処理＞
以下、上記実施形態の第１の変形例の動作について、構造化文書検索システム５０における検索処理を例に、上記実施形態と相違する点を中心に図７のフローチャートを参照して説明する。なお、図７において、図６のフローチャートと同様のステップには同一参照符号を付してある。
【００６３】
まず、ユーザがクライアント端末２０を操作することにより、当該クライアント端末２０から構造化文書検索システム５０に対して、ネットワーク３０経由で検索要求が送出されたものとする（ステップＳ１１）。この検索要求に含まれている検索式は上記実施形態と同様に一括同一視条件を含むものとする。この場合、上記実施形態と同様にステップＳ１２乃至Ｓ１６が行われて、一括同一視指定される個々の同一視条件が設定される。
【００６４】
すると検索処理部５４は、ステップＳ１３で解析されたクエリ（検索式）で同一視除外条件が指定されているか判定する（ステップＳ２１）。第１の変形例において、このクエリは一括同一視条件に加えて同一視除外条件も指定している（含んでいる）ものとする。
【００６５】
解析されたクエリで同一視除外条件が指定されている場合（ステップＳ２１）、検索処理部５４は、ステップＳ１６で設定された複数の同一視条件、即ち一括して指定された複数の同一視条件の中から、同一視除外条件で指定された同一視条件だけを除外する（ステップＳ２２）。この同一視除外条件で指定された同一視条件を除外する処理について、具体例を挙げて説明する。
【００６６】
まず、セッション＃１で以下の検索式（クエリ）
/item/name [./text() ftcontains “社員Aさん” all insensitive except case]
を含む検索要求が実行されるものとする。このとき、同一視条件情報記憶部５３０に格納されている同一視条件情報５３１が図３の状態にあるものとする。
【００６７】
上記クエリでは、一括同一視条件“all insensitive”が指定されている。このため上記実施形態と同様に、“all insensitive”が“case insensitive width insensitive kana insensitive kanacase insensitive”に自動的に置き換えられる（ステップＳ１６）。
【００６８】
また上記クエリでは、同一視除外条件“except case”が指定されている（ステップＳ２１）。このため検索処理部５４は、“case insensitive width insensitive kana insensitive kanacase insensitive”から英数字の大文字小文字同一視条件（case insensitive）を除外する（ステップＳ２２）。つまり検索処理部５４は、“case insensitive width insensitive kana insensitive kanacase insensitive”を、英数字の大文字小文字同一視条件（case insensitive）が除外された“width insensitive kana insensitive kanacase insensitive”に自動的に置き換える。
【００６９】
これにより前述のクエリは、以下のクエリ
/item/name [./text() ftcontains “社員Aさん” width insensitive kana insensitive kanacase insensitive]
と同等となる。
【００７０】
以降の動作は上記実施形態と同様であり、索引管理部５５は、検索処理部５４によって解析されたクエリ（検索式）に含まれている検索キーワードと現在設定されている個々の同一視条件（ここでは、一括指定された複数の同一視条件から、同一視除外条件で指定された同一視条件が除外された残りの同一視条件）とに従って、当該検索キーワードを展開する（ステップＳ１７）。なお、同一視除外条件が指定されていない場合には（ステップＳ２１）、ステップＳ２２をスキップしてステップＳ１７が実行される。ステップＳ１７が実行されると、上記実施形態と同様にステップＳ１８及び１９が実行される。
【００７１】
上記実施形態の第１の変形例によれば、同一視除外条件により一括同一視指定の対象外とする同一視条件を設定できるので、ある同一視条件だけ同一視する、またはしないといった同一視検索でも一括同一視指定が使える。このため一括同一視指定をより有効に利用することができる。また、同一視除外条件をクエリ中に設定（記述）できるので、一括同一視指定を利用しながら、クエリ単位で同一視条件を変更できる。
【００７２】
［第２の変形例］
上記実施形態の第１の変形例では、所望の同一視条件を一括同一視指定の対象外とする検索が必要な場合、ユーザは、その都度検索式で同一視除外条件を指定する必要がある。
【００７３】
そこで、検索式で同一視除外条件を指定しなくても、所望の同一視条件を一括同一視指定の対象外とすることを可能とする上記実施形態の第２の変形例について説明する。第２の変形例の特徴は、ユーザから要求されたセッションに対応付けられている一括同一視指定の対象となる複数の同一視条件ごとに、同一視する／しない（適用／非適用）の設定を更新できるようにしたことにある。
【００７４】
＜同一視条件設定処理＞
以下、上記実施形態の第２の変形例の動作について、構造化文書検索システム５０における同一視条件設定処理を例に図８のフローチャートを参照して説明する。  
まず、ユーザがクライアント端末２０を操作することにより、当該クライアント端末２０から構造化文書検索システム５０に対して、現在確立しているセッションを用いて、ネットワーク３０経由で同一視条件設定要求が送出されたものとする（ステップＳ３１）。この同一視条件設定要求は、予め定められている同一視条件ごとに、同一視する／しない（適用／非適用）の情報を含む。
【００７５】
要求処理部５２は、クライアント端末２０からの同一視条件設定要求を受け取ると、当該同一視条件設定要求を同一視条件管理部５３に渡して同一視条件設定を要求する（ステップＳ３２）。
【００７６】
すると同一視条件管理部５３は、同一視条件設定要求に含まれている同一視する／しない（適用／非適用）の情報に従って、同一視条件情報記憶部５３０に格納されている同一視条件情報５３１の中で、該当するセッションに対応付けられている一括同一視指定の対象となる複数の同一視条件ごとの同一視する／しない（適用／非適用）の情報（セッション対応同一視情報）を更新する（ステップＳ３３）。ここで、該当するセッションは、クライアント端末２０からの同一視条件設定要求の送信に用いられたセッションを指す。
【００７７】
もし、同一視条件設定要求で英数字の大文字小文字同一視条件のみ同一視しないこと（非適用）が指定されているならば、ステップＳ３３の実行により、英数字同一視条件及び仮名同一視条件のうち、英数字の大文字小文字同一視条件のみ同一視しないに変更される。これは、クエリにより、その都度同一視除外条件“except case”を指定することと等価である。
【００７８】
上記実施形態の第２の変形例によれば、ユーザから要求されたセッションに対応付けられている一括同一視指定の対象となる複数の同一視条件ごとに、同一視する／しない（適用／非適用）の設定を更新できるため、一括同一視指定の対象となる同一視条件の設定を当該セッションにおいて継続的に有効にできる。よってユーザは、同一視除外条件をクエリごとに設定する必要がない。
【００７９】
［第３の変形例］
上記実施形態（並びに当該実施形態の第１及び第２の変形例）では、一括同一視指定の対象として設定された個々の同一視条件に従って、検索キーワードが無条件に展開される。しかし、展開された語彙にヒットしなかった場合には、その展開に要した処理コストが無駄となる。
【００８０】
そこで、このような無意味な検索キーワードの展開を防止できるようにした上記実施形態の第３の変形例について説明する。
【００８１】
図９は上記実施形態の第３の変形例で適用される索引管理部５５の構成を示すブロック図である。索引管理部５５は、文字種情報記憶部５５０を含む。文字種情報記憶部５５０は、データベース４２に登録されるＸＭＬ文書の木構造上の階層ごとに、即ちＸＭＬ文書の構造（パス）ごとに、その直下のテキストノードの文字種（テキストの文字種）と文字数を管理するのに用いられる文字種情報５５１を格納する。
【００８２】
図１０は文字種情報５５１の一例を示す。第３の変形例において、文字種情報５５１は表形式で管理される。文字種情報５５１は、列要素としてパスと文字種を含む。ここでは文字種が、「英数字」、「仮名」及び「その他」の３種であるものとする。文字種情報５５１は、各パスについて、当該パスを表す文字列（ＸＰａｔｈ表記文字列）と、データベース４２に登録されるＸＭＬ文書の当該パスの直下のテキストノードの文字種ごとの文字数とを、それぞれ値（表要素の値）として持つ。このパスごとの、当該パスを表す文字列と文字種ごとの文字数との組からなる情報を、パス対応文字種情報と呼ぶ。図１０の文字種情報５５１は、簡略化のために、データベース４２に上記実施形態で挙げたＸＭＬ文書だけが登録されている場合の例を示している。このＸＭＬ文書の例では、<id>ノードの直下のテキストノードの値は“0001”であり、<name>ノードの直下のテキストノードの値は“社員Aさん”である。このため、図１０において、パス「/item/id」に対応付けられた文字種「英数字，仮名，その他」の文字数は「４，０，０」であり、パス「/item/name」に対応付けられた文字種「英数字，仮名，その他」の文字数は「１，４，０」である。
【００８３】
データベース４２にＸＭＬ文書が全く登録されていないときは、文字種情報５５１は空である。ＸＭＬ文書がデータベース４２に登録されて、新たなパス（ＸＰａｔｈ表記）が増える度に、文字種情報５５１の行が追加され、そのＸＭＬ文書に含まれている当該パスの直下のテキストノードの文字種ごとの値（文字数）が登録される。また、既に文字種情報５５１に登録されているパスについては、新たに登録されたＸＭＬ文書に含まれている当該パスの直下のテキストノードの文字種の文字数だけ、既に登録されている当該文字種の文字数が増加される。同様に、ＸＭＬ文書がデータベース４２から削除されると、当該削除されるＸＭＬ文書に含まれている当該パスの直下のテキストノードの文字種の文字数だけ、既に登録されている当該文字種の文字数が減少される。また、ＸＭＬ文書の削除により存在しなくなったパスについては、そのパスに関する行が文字種情報５５１から削除される。
【００８４】
＜文書登録処理＞
次に、上記実施形態の第３の変形例の動作について、構造化文書検索システム５０における文書登録処理を例に図１１のフローチャートを参照して説明する。なお、図１１において、図４のフローチャートと同様のステップには同一参照符号を付してある。
【００８５】
今、ユーザが、データベース４２に登録されるべきＸＭＬ文書を指定して、当該ＸＭＬ文書の登録を指示するための操作を、クライアント端末２０上で行ったものとする。するとクライアント端末２０は、構造化文書検索システム５０に対して、指定のＸＭＬ文書をデータベース４２に登録させるための登録要求（文書登録要求）をネットワーク３０経由で送出する（ステップＳ１）。
【００８６】
要求処理部５２は、クライアント端末２０からの登録要求を受け取ると、当該登録要求を文書登録部５６に渡してＸＭＬ文書（ＸＭＬドキュメント）の登録を要求する（ステップＳ２）。文書登録部５６は、クライアント端末２０からの登録要求を要求処理部５２を介して受け取ると、当該要求で指定されたＸＭＬ文書のパースを開始する（ステップＳ３）。すると、上記実施形態と同様に、ＸＭＬ文書から要素（ノード）が抽出される都度（ステップＳ４）、そのノードについて、索引管理部５５による索引登録処理が行われる（ステップＳ５）。
【００８７】
次に索引管理部５５は文字種情報管理手段として機能して、索引登録の対象となったノード（要素）の内容（値）がテキストの場合、当該テキストを対象に文字種を識別すると共に文字数を計算し、文字種情報記憶部５５０に格納されている文字種情報５５１のうち、当該ノードのパスに対応付けられている当該識別された文字種の文字数を更新（例えば、当該計算された文字数だけ増加）する（ステップＳ４０）。図７のフローチャートが図４のフローチャートと相違する点は、このステップＳ４０が追加されたことである。なお、索引管理部５５の文字種情報管理手段としての機能を、当該索引管理部５５から独立の手段に持たせることも可能である。
【００８８】
文書登録部５６は、索引管理部５５によって文字種情報５５１が更新されると（ステップＳ４０）、抽出されたノードをデータベース４２に格納するドキュメント格納処理を行う（ステップＳ６）。そして文書登録部５６は、未処理のノードが残っているならば（ステップＳ７）、上記ステップＳ４に戻って次のノードについて処理を継続する。
【００８９】
＜検索処理＞
次に、第３の変形例で適用される構造化文書検索システム５０における検索処理について、上記実施形態と相違する点を中心に図１２のフローチャートを参照して説明する。なお、図１２において、図６のフローチャートと同様のステップには同一参照符号を付してある。
【００９０】
まず、ユーザがクライアント端末２０を操作することにより、当該クライアント端末２０から構造化文書検索システム５０に対して、ネットワーク３０経由で検索要求が送出されたものとする（ステップＳ１１）。この検索要求に含まれている検索式は上記実施形態と同様に一括同一視条件を含むものとする。この場合、上記実施形態と同様にステップＳ１２乃至Ｓ１６が行われて、一括同一視指定される個々の同一視条件が設定される。
【００９１】
すると索引管理部５５は、文字種情報記憶部５５０に格納されている文字種情報５５１から検索対象パスに固有の文字種情報（パス対応文字種情報）を取得する（ステップＳ５０）。このステップＳ５０において、索引管理部５５は同一視条件除外手段として機能して、取得された文字種情報に含まれている文字種ごとの数（文字数）に基づいて、ヒットすることがない無駄な同一視条件を特定し、その特定された同一視条件を一括同一視指定された複数の同一視条件から除外する。図１２のフローチャートが図６のフローチャートと相違する点は、このステップＳ５０が追加されたことである。このステップＳ５０の詳細な手順については後述する。なお、上記ステップＳ５０を、検索処理部５４が検索対象パスに固有の文字種情報（パス対応文字種情報）を索引管理部５５に問い合わせることで、当該検索処理部５４が行うようにしても構わない。
【００９２】
一方、検索要求に含まれている検索式で一括同一視条件が指定されていない場合（ステップＳ１４）、ステップＳ１５及びＳ１６をスキップしてステップＳ５０が実行される。ここでは、検索式で直接指定されている同一視条件の中から上記特定された同一視条件が除外される。
【００９３】
索引管理部５５は、ステップＳ５０が実行されると、解析されたクエリ（検索式）に含まれている検索キーワードと当該ステップＳ５０で除外されなかった同一視条件とに従って、当該検索キーワードを展開する（ステップＳ１７）。次に索引管理部５５は、展開後の全ての検索キーワードに対し、データベース４２に格納されている索引を用いて、検索条件に合致するノードのリストを検索結果として取得する（ステップＳ１８）。ここでは、ヒットすることがない無駄な同一視条件は除外され、当該無駄な同一視条件に従う検索キーワードの展開は抑止されている。つまり検索キーワードの無駄な展開は抑止される。このため検索の高速化が図れる。
【００９４】
＜無駄な同一視条件を除外する処理＞
次に索引管理部５５による上記ステップＳ５０の処理（即ち無駄な同一視条件を除外する処理）の詳細な手順について、図１３のフローチャートを参照して説明する。
【００９５】
まず索引管理部５５は、文字種情報記憶部５５０に格納されている文字種情報５５１から、検索対象パスに固有の文字種情報（パス対応文字種情報）を取得する（ステップＳ６１）。次に索引管理部５５は、取得された文字種情報中の文字種「英数字」の数（文字数）が０であるかを判定する（ステップＳ６２）。もし、英数字の数が０の場合（ステップＳ６２）、索引管理部５５は英数字同一視条件が指定されていても検索でヒットすることはないとして、当該英数字同一視条件を同一視条件から除外する（ステップＳ６３）。即ち索引管理部５５は、英数字同一視条件を“同一視しない”（非適用）として設定する。一方、英数字の数が０でない場合（ステップＳ６２）、索引管理部５５はステップＳ６３をスキップする。
【００９６】
同様に索引管理部５５は、取得された文字種情報中の文字種「仮名」の数（文字数）が０であるかを判定する（ステップＳ６４）。もし、仮名の数が０の場合（ステップＳ６４）、索引管理部５５は仮名同一視条件が指定されていても検索でヒットすることはないとして、当該仮名同一視条件を同一視条件から除外する（ステップＳ６５）。即ち索引管理部５５は、仮名同一視条件を“同一視しない”（非適用）として設定する。一方、仮名の数が０でない場合（ステップＳ６４）、索引管理部５５はステップＳ６５をスキップする。なお、上述の無駄な同一視条件を除外する処理（ステップＳ６１乃至Ｓ６５）を、検索処理部５４が検索対象パスに固有の文字種情報（パス対応文字種情報）を索引管理部５５に問い合わせることで、当該検索処理部５４が行うことも可能である。
【００９７】
上記実施形態の第３の変形例によれば、無駄な同一視条件が除外されることにより、検索キーワードの無駄な展開が抑止される。これにより、検索の処理コストが減り、検索を高速化できる。また、無駄な同一視条件を除外する処理が自動的に行われるので、ユーザは検索キーワードを構成する文字種を意識せず同一視検索のための検索式を設定できる。
【００９８】
上記実施形態及びその変形例では、構造化文書がＸＭＬ文書である場合を想定している。しかし、本発明は、例えば、ＳＧＭＬ（Standard Generalized Markup Language）文書のようなＸＭＬ文書以外の構造化文書にも同様に適用できる。
【００９９】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【０１００】
【図１】本発明の一実施形態に係る構造化文書検索システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図。
【図２】図１に示される構造化文書検索システムの主として機能構成を示すブロック図。
【図３】同実施形態で適用される同一視条件情報の一例を示す図。
【図４】同実施形態における文書登録処理の手順を示すフローチャート。
【図５】同実施形態で適用される索引の具体例を示す図。
【図６】同実施形態における検索処理の手順を示すフローチャート。
【図７】同実施形態の第１の変形例における検索処理の手順を示すフローチャート。
【図８】同実施形態の第２の変形例における同一視条件設定処理の手順を示すフローチャート。
【図９】同実施形態の第３の変形例で適用される索引管理部の構成を示すブロック図。
【図１０】同第３の変形例で適用される文字種情報の一例を示す図。
【図１１】同第３の変形例における文書登録処理の手順を示すフローチャート。
【図１２】同第３の変形例における検索処理の手順を示すフローチャート。
【図１３】同第３の変形例における無駄な同一視条件を除外する処理の手順を示すフローチャート。
【符号の説明】
【０１０１】
１０…データベースサーバ、１１…メモリ、２０…クライアント端末、３０…ネットワーク、４０…外部記憶装置、４１…データベース管理プログラム、４２…データベース、５０…構造化文書検索システム、５１…データベース管理システム、５２…要求処理部、５３…同一視条件管理部、５４…検索処理部、５５…索引管理部、５６…文書登録部、５３０…同一視条件情報記憶部、５３１…同一視条件情報、５５０…文字種情報記憶部、５５１…文字種情報。
【図１】
0004550876.tif 000002
【図２】
0004550876.tif 000003
【図３】
0004550876.tif 000004
【図４】
0004550876.tif 000005
【図５】
0004550876.tif 000006
【図６】
0004550876.tif 000007
【図７】
0004550876.tif 000008
【図８】
0004550876.tif 000009
【図９】
0004550876.tif 000010
【図１０】
0004550876.tif 000011
【図１１】
0004550876.tif 000012
【図１２】
0004550876.tif 000013
【図１３】
0004550876.tif 000014