JP2014089646A - 電子データ処理装置、及び電子データ処理方法 - Google Patents

Abstract

【課題】全文検索エンジンを使用して、様々なスキーマの大量の階層構造データ（例えばXML）に対して、高速に、かつ、パスを様々な形式で指定して検索可能にし、さらに、属性検索との複合検索も可能にする技術を提供する。
【解決手段】XMLデータをTable構造のデータに変換する機能と、Table構造のデータからインデクスを生成する機能と、インデクスをもとに検索する機能を有している。Table構造のデータを生成する際は、１つのＸＭＬ要素値・属性値を１行で表す。また、１行を、XML階層を表す列、要素・属性の識別を表す列、要素値・属性値を表す列の３列に分ける。XML階層を表す列には、最上位階層と最下位階層を識別するための文字列を含める。XMLの検索を行う際には、３列のTable型のクエリを使用する。また、階層の順序指定をフレーズ検索によって実現する。
【選択図】図６

Description

本発明は、電子データ処理装置、及び電子データ処理方法に関し、例えば、コンピュータ上の階層構造データ（XML(eXtensible Markup Language)データ）を検索するための技術に関するものである。

近年コンピュータ及び検索エンジンの発達により、ハードディスクなどの記憶装置上に格納された様々なファイルを検索可能となっている。

例えば、全文検索エンジンSolr（非特許文献1参照）では、ファイル内のテキストデータを検索可能である。Solrは、ドキュメント毎にデータの種類を区別した検索(属性検索)を行うことが可能である。データの種類(属性)はSolrではフィールドと呼ばれ、フィールド名で区別される。Solrに対して、[フィールド名]:[検索式]のような検索クエリを与えると、フィールドを指定した検索が可能である。例えば、ファイル名のフィールド名が「fileName」、本文のフィールド名が「contents」である場合に、fileNameが「sample.txt」、contents内に「サンプル」を含むドキュメントを検索する際には、「fileName:sample.txt AND contents:サンプル」のよな検索クエリをSolrに与えることで検索可能である。なお、Solrでは「AND」や「OR」のような論理演算子を使用することも可能である。ANDは論理積を表し、ORは論理和を表す。また、Solrを導入したサーバを複数連結させてスケーラビリティを向上させることも可能である。これにより、数億個のドキュメントを検索対象とすることも可能である。

また、検索エンジンには、XMLデータ（以降、単にXMLと呼ぶことがある）のような階層型のデータを検索可能なものもある。例えばXMLデータベース（XMLDB）では、検索対象のXMLのスキーマの事前定義が不要であるものが多い（非特許文献２参照）。そのため、様々なXMLデータに対して、XMLの階層（階層構造）を指定した検索が可能である。例えば、XMLDBに対して、「/patient/birthDate=”20010101”」のような検索クエリを与えると、図２ＡのようなXMLを検索可能である。なお、この例の検索クエリは、[要素名]/[要素名]/[要素名]=[要素値]のような書式で表現されている。XMLスキーマの事前定義が不要であるため、未知の形式のXMLであっても検索可能である。

関口宏司, "Apache Solr入門", 技術評論社, 2010 XMLDB.JPホームページ(http://www.xmldb.jp/)

しかしながら、非特許文献１の技術（全文検索の技術）では、XMLデータのような階層構造を持つデータに対して、スキーマ（データベースの構造）の事前定義なしで階層構造を指定した検索を行うことが困難である。階層構造を指定して検索できると、属性を指定した検索ができるようになり検索ノイズが減り、ピンポイントの検索結果が得られるという利点がある。

例えば、図２ＡのようなXMLファイルにおいて、パス「/patient/birthDate」の値が「20010101」である文書を検索する際に、SolrはXMLの階層（パス）を指定して検索することができない。例えば、「contens:patient AND contents:birthDate AND contents:20010101」のような検索クエリを与えた場合、図２ＡのようなXML以外に、図２ＢのようなXMLも検索ヒットしてしまう。図２Ｂの例では、「patient」はXML要素名ではなく、「type」というXML要素の値である。また、「20010101」は「birthdate」要素の値ではなく、「id」属性の値であり、意図した検索結果ではない。

SolrでXMLのパス毎にフィールドを定義すれば、XMLを検索することは可能である。例えば、「patient/birthDate」のようなフィールドを定義しておき、該当する値をインデクシングしておけば、「patient/birthDate:20010101」のような検索クエリでXMLパスに該当する値を検索可能となる。しかし、この方法は、事前にXMLスキーマを分析し、すべてのパス毎にフィールドを定義しておかなければならない。このため、未知のXMLを検索不可能であり、またXMLスキーマに変更があった場合も検索用インデクス(以降、インデクスと略す)の再生成が必須となってしまう。一般にインデクス生成は膨大な時間がかかるため、この方法は現実的でないことが多い。また、この方法は、パスの一部を検索条件として検索することができない。例えば、図２ＡのようなXMLに対して、ルート要素からのパスである「patient/homeTown/city」を指定した検索(完全パスによる検索)は可能であるが、パスの一部である「homeTown/city」だけを指定した検索(部分パスによる検索)ができない。XMLのパスは一般に複雑な文字列になることが多いため、検索する度に完全パスを指定するのはユーザにとって負担となることから、部分パスを指定できることは重要である。「patient/homeTown/city」というフィールド以外に、「homeTown/city」というフィールドや、「city」というフィールドを定義しておき、該当する値をインデクシングしておけば、部分一致パスでの検索も可能になるが、部分一致パスのパターンの数だけインデクシングが必要になり、インデクス量が膨大になってしまう。
以上のように全文検索エンジンでは、一般にXML要素を認識した検索が困難である。

この点、XMLDBは、全文検索エンジンと比較してスケーラビリティが低く、検索性能も劣るため、大量データの検索は困難である。また、XMLの検索に特化されており、ファイル内の全文検索やファイル名などの属性検索との複合検索が困難である。

一方、メタデータの保存形式としてXMLが用いられることが多い。従って、全文検索エンジンを使用して、XMLデータ及び非XMLデータが混在したデータに対して属性検索を可能とする仕組みが望まれる。

本発明はこのような状況に鑑みてなされたものであり、全文検索エンジンを使用して、様々なスキーマの大量の階層構造データ（例えばXML）に対して、高速に、かつ、パスを様々な形式で指定して検索可能にし、さらに、属性検索との複合検索も可能にする技術を提供する。

上記課題を解決するために、本発明では、XMLデータを表構造のデータに変換し、1つの階層のデータを表の1行に対応させ、当該行において、階層構造、要素と属性の区別(以降、ノード種別と呼ぶことがある)、要素値または属性値(以降、ノード値と呼ぶことがある)を、それぞれ別の列に対応させてインデクスを生成する。検索時には、階層構造、ノード種別、ノード値を、区別して検索クエリを生成し、インデクスと比較することでXMLを検索可能にする。

即ち、本発明による電子データ処理装置は、階層構造データを解析し、階層構造データを検索する際に用いられるインデクスデータを生成する。当該電子データ処理装置は、階層構造データを解析するための解析ツールと、インデクスデータを生成するためのプログラムを含む、管理情報を格納する記憶装置と、解析ツールを用いて階層構造データを解析し、プログラムを実行してインデクスデータを生成するプロセッサと、を有する。ここで、階層構造データは、各階層において、要素及び／又は属性を表す少なくとも１つの文字列と、当該文字列の要素値或いは属性値とによって構成されるパス情報を有するものとする。より詳細には、プロセッサは、階層構造データの各階層で定義されるパス情報に対して解析ツールを適用し、階層内及び階層間における、繋がりとして意味のある複数の文字列の文字列グループの識別情報と、各文字列グループにおける要素又は属性とその要素値又は属性値との対応関係を示す表構造データに、階層構造データを変換する。次に、プロセッサは、表構造データを参照し、文字列、要素値、及び属性値の表構造データにおける位置の情報と、文字列グループの識別情報と、を含む階層構造データについてのインデクスデータを生成する。

本発明によれば、全文検索エンジンを使用して、様々なスキーマの大量の階層構造データ（例えばXML）に対して、高速に、かつ、パスを様々な形式で指定して検索可能となり、さらに、属性検索との複合検索も可能となる。
なお、上述した以外の課題、構成及び効果は、以下の本発明を実施するための形態および添付図面によって明らかになるものである。

本発明の実施形態に係るXMLデータ処理装置の概略構成を示す図である。 XMLの一例を示す図である。 設定データの一例を示す図である。 Tableデータの一例を示す図である。 インデクスデータの一例を示す図である。 検索画面の一例を示す図である。 Tableデータ生成処理を説明するためのフローチャートである。 インデクス生成処理の概要を説明するためのフローチャートである。 インデクス生成処理の詳細を説明するためのフローチャートである。 検索処理の概要を説明するためのフローチャートである。 検索処理の一部を説明するためのフローチャートである。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

以後の説明では「プログラム」を主語として説明を行うが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

＜XMLデータ処理装置の構成＞
図１は、本発明の実施形態によるXMLデータ処理装置（インデックス作成機能とXMLデータ検索機能を併せ持つ電子データ処理装置）10の概略構成を示す機能ブロック図である。

XMLデータ処理装置10は、必要な演算処理及び制御処理等を行う中央処理装置（プロセッサ）100と、データの入出力を行うための入出力装置110と、中央処理装置100での処理に必要なプログラムを格納するプログラムメモリ120と、中央処理装置100での処理対象となるデータまたは処理後のデータを格納する記憶装置130と、プログラムが処理過程で生成する中間データを格納するデータメモリ140と、を有している。

入出力装置110は、データを表示するための表示装置111やプリンタ（図示せず）等で構成される出力デバイスと、表示されたデータに対してメニューを選択するなどの操作を行うためのキーボード112、マウスなどのポインティングデバイス113と、を有している。

プログラムメモリ120は、XMLファイルの階層構造をもとに表構造のデータを生成するTableデータ生成プログラム121と、Tableデータ及びXMLデータをもとに検索用インデクスを生成するインデクス生成プログラム122と、インデクスをもとにユーザからの検索クエリから該当するXMLデータを検索する検索プログラム123と、を格納している。なお、各処理プログラムは、プログラムコードとしてプログラムメモリ120に格納されており、中央処理装置100が各プログラムコードを実行することによって各処理が実現される。

記憶装置130は、XMLファイル群が格納されたXMLデータ131と、プログラムを実行する上での設定情報を格納した設定データ132、インデクスが格納されたインデクスデータ133と、を格納している。なお、記憶装置130は、ネットワークを介して遠隔的に配置されていているストレージシステムであってもよい。

データメモリ140は、XMLデータ131を基に生成されるTableデータ141を格納している。また、プログラムを実行する際に一時的に使用されるデータ(図示せず)が格納される。

以上に述べた処理プログラム・データ・各プログラム等は、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＭＯ、フロッピー（登録商標）ディスク、ＵＳＢメモリ等の種々の記録媒体に格納して提供することもできる。

＜XMLデータの例＞
図２は、記憶装置130内のXMLデータ131の一例を示す図である。本発明の実施形態では、XMLデータ131に登録された各ファイル(ファイル001.xml、002.xml、003.xml、・・・)は、様々なスキーマで定義されたXMLファイルが混在しており、例えば図２Ａや図２Ｂのようなファイルが含まれる。

図２Ａにおいて、ノード201及び205は第１階層の情報に、ノード202及び204は第２階層の情報に、ノード203は第３階層の情報に、それぞれ相当する。

＜設定データの例＞
図３は、記憶装置130内の設定データ132の一例を示す図である。設定データ132は、XMLデータを解析する際に用いられる一種の制御データ（解析ツール）であり、本発明の実施形態で使用される各種パラメータが設定（定義）され、例えばXML形式で保存される。図３に示されるように、この設定データ例では、XMLデータ以外のための設定データ（<fieldType name="fileName">）と、XMLデータ用の設定データ（<fieldType name="xml">）が定義されている。また、図３の設定データはXML形式で記述されているが、システムが理解できさえすれば形式は問わない。

fieldType301及び303は、インデクス生成時、検索時に使用するフィールドの定義情報を定義する。また、fieldType301及び303のname属性でフィールド名が設定（定義）される。

tokenizer302及び305は、インデクス生成時及び検索時に文字列をトークナイズする際に使用されるtokenizerの情報を定義している。ここで、トークナイズとは、文字列をトークン(Keyword)に分割する処理を言う。例えばtokenizer302に設定されているWhitespaceTokenizerは、空白文字をKeywordの区切りと認識してKeyword分割処理を行うことを意味している。ただし、tokenizerは様々な種類があり、任意のものが適用可能である。

また、tokenizer304に設定されているcolumnTokenizerは、XMLデータから生成されるTableデータや、XMLデータの検索クエリを解析するためのtokenizerである。
columnTokenizerは、fieldTypeのname属性がxmlであった場合に設定される。

＜Tableデータ＞
図４は、データメモリ140内のTableデータ141の一例を示す図である。図４は、設定データ132で定義されているTableTokenizerを用いて図２ＡのXMLファイルを解析することにより、Tableデータに変換した例を示している。

Tableデータ141は、XMLデータ131を表形式に変換して生成されたデータである。Tableデータ141は、DocID401と、RowID402と、ColumnID403とによって構成される。また、ColumnID403は、パス404、type405、及び値406の３列のデータで構成される。

DocID401は、XML毎に設定される識別用IDである。RowID402は、１つのXMLデータのノード値毎に設定される識別用IDである。

ColumnID403は、３列のデータで構成される。第１列目はXMLの階層（パス）を表す。例えば、元のXMLのルート要素からのパスが「patient/birthDate」であった場合は、「xmlRoot patient birthDate xmlLeaf」となる。先頭の「xmlRoot」は先頭識別子であり、終端の「xmlLeaf」は終端識別子である。これらは、検索を行う際に、XMLの階層を完全パス（最上位階層から最下位階層までを全て指定する階層指定方法）で指定する際に使用する。その他の文字列は、パスを表す文字列における「/」の部分に空白を挿入している。なお、「xmlLeaf」の直前の文字列は、ノード値に対応するノード値である。例えば、ここで、あるXMLデータに<A><B>XXX</B></A>から構成されるノードが含まれ、別のXMLデータに<C><A><B>XXX</B></A></C>から構成されるノードが含まれる場合を考える。そして、単に<A><B>を有するXMLデータを検索するという検索クエリを用いるとすると、上記２つのXMLデータの両方が検索結果として抽出される。そこで、xmlRootを検索クエリに付加すると、前者のXMLデータはヒットするが、後者のXMLデータはヒットしなくなり、両者を区別して検索することができるようになる。

ColumnID403の第２列目は、各パス404のxmlLeafの直前に配置された情報（例えば、id、family、personal、birthDate、city）に対応する第３列目の文字列（値406）が、要素か属性かの区別（type）を表す。「element」は第３列目の値が要素値であることを表し、「attribute」は第３列目の値が属性値であることを表す。このようにtype405を設けたのは、RowID２のパスを例にすると、パスの設定の仕方によっては、name（要素）の次に要素としてのfamilyが定義されることもありうるし、属性としてのfamilyが定義されることもあり、これらを区別するためである。
第３列目は、要素値または属性値を表している。

＜インデクスデータ＞
図５は、記憶装置130内のインデクスデータ133の一例を示す図である。
インデクスデータ133は、XMLファイル（図２）や、Tableデータ141（図４）を基に、fieldType毎に生成される。図５Ａは、Tableデータ141から生成されたインデクスデータである。また、図５Ｂは、fieldTypeが「fileName」のデータ（非ＸＭＬ）から生成されたインデクスデータである。さらに、図５Ｃは、DocID毎のfieldType毎の値（DocIDとfileNameとの対応関係を示す情報）を格納するデータである。ただし、xmlフィールドのデータは含まれない。インデクスデータ133は、図５Ａ〜Ｃのようなデータで構成される。

図５Ａにおいて、Keyword501は、Tableデータ141におけるColumnID1〜3内の文字列を、fieldType毎に設定されたtokenizerによって分割されたKeyword単位で格納される。DocID502は、Tableデータ141における当該Keyword501のDocIDである。RowID503は、Tableデータ141における当該Keyword501のRowID402を示している。同じRowIDを示すKeywor501は、同一パスにおいて連続した文字列、type及び値であることを示している。ColumnID504は、Tableデータ141における当該Keyword501が出現するColumnの列の識別IDである。Position505は、Tableデータ141における該当ColumnID403において、当該Keyword501が出現する位置を表す。この位置は、tokenizerで分割されたKeywordの出現する順番を表す。

＜検索画面＞
図６は、XMLデータを検索する際に使用される検索画面(GUI)の一例を示す図である。
図６に示されるように、GUIのウインドウ601では、上側の領域に検索条件を入力する検索ボックス602と検索ボタン603が表示され、下側の領域には、602に入力した検索条件の検索結果604が表示される。図６では、xml内の階層データの検索と、ファイル名のAND検索の検索結果が表示された状態が示されている。xmlのパスは、先頭識別子と終端識別子を含めたフレーズ検索によって表現されており、すなわち完全一致検索が実行された状態を表している。なお、検索条件に含まれるダブルクォーテーションマーク（“”）は、その中に含まれる文字列の順序に意味を持たせたいときに用いるフォールド検索のための記号である。

＜XMLデータ処理装置における処理概要＞
上述の構成を有するXMLデータ処理装置10において行われる処理の概要について説明する。
まず、中央処理装置100は、Tableデータ生成プログラム121を用いて、記憶装置130におけるXMLデータ131を読み込み、XMLデータを解析して得られるTableデータ141をデータメモリ140に格納する。

次に、インデクス生成プログラム122が実行される。インデクス生成プログラム122は、記憶装置130から設定データ132、データメモリ140からTableデータ141を読み込み、設定データ132に設定されているfieldTypeのインデクスを生成し、インデクスデータ133として記憶装置130に格納する。

そして、検索プログラム123は、生成されたインデクスデータを用いて検索処理を実行する。検索処理は、ユーザによって検索画面において検索クエリ602が入力され、検索ボタン603が押下されると、実行される。より詳しくは、検索プログラム123は、検索クエリ602に含まれる検索条件を解析し、インデクスデータ133から検索条件に該当するXMLファイルを検索し、検索結果を検索画面に表示する。なお、それぞれの処理について、以下詳細に説明する。

＜Tableデータ生成処理＞
図７は、Tableデータ生成プログラム121が実行するTableデータ生成処理を説明するためのフローチャートである。Tableデータ生成処理では、図２ＡのようなXMLデータから、図４のようなTableデータ141を生成する。ここでの動作主体は、Tableデータ生成プログラム121である。

ステップ701では、Tableデータ生成プログラム121は、XMLデータ131から未処理のXMLファイルを1つ選択する。

ステップ702では、Tableデータ生成プログラム121は、選択したXMLファイルを解析する。具体的には、XMLの要素値及び属性値を、階層構造(パス)を認識して抽出する。図２Ａのノード201を例にすると、「patient」「id」「001」が抽出される。

ステップ703では、Tableデータ生成プログラム121は、その中から未処理の要素値または属性値とそのパスを選択する。以降、図２Ａにおける「Alex」という属性値を選択した例で説明する。

ステップ704では、Tableデータ生成プログラム121は、階層を表す文字列群をColumnID1に格納する。上記の例の場合は「patient name personal」である。この際、先頭識別子として「xmlRoot」を先頭に、終端識別子として「xmlLeaf」を終端に付与する。上記の例の場合は、ColumnID1には、「xmlRoot patient name personal xmlLeaf」が格納される。

ステップ705では、Tableデータ生成プログラム121は、要素値の場合は「element」を、属性値の場合は「attribute」をColumnID2に格納する。上記の例の場合は「attribute」が格納される。要素か属性かは、例えば、XMLのparserを用いることによって区別される。

ステップ706ではTableデータ生成プログラム121は、要素値または属性値をColumnID3に格納する。上記の例の場合は、「Alex」が格納される。

ステップ707では、Tableデータ生成プログラム121は、ステップ702で解析した結果において、全ての要素値または属性値を処理したか否かを判定する。真であれば、処理はステップ708に進み、偽であれば、処理はステップ703に戻る。

ステップ708では、Tableデータ生成プログラム121は、XMLデータ131における全XMLファイルを処理したか否かを判定し、真であれば処理を終了し、偽であればステップ702に戻る。

＜インデクス生成処理＞
図８は、インデクス生成プログラム122が実行するインデクス生成処理の概要を説明するためのフローチャートである。インデクス生成処理では、図２のXMLファイルや、図４のTableデータから、図５のようなインデクスデータを生成する。ここでの動作主体は、インデクス生成プログラム122である。

ステップ801では、インデクス生成プログラム122は、記憶装置130から、XMLデータ131、設定データ132、及びTableデータ141を読み込む。

ステップ802では、インデクス生成プログラム122は、設定データ132におけるxmlフィールド(fieldTypeのname属性が「xml」のフィールド)でないフィールド（非xmlフィールド）のインデクス生成を行う。例えば、図２ＡにおけるfileNameフィールドに対してインデクス生成する場合を考える。この場合、fileNameフィールドの値は、「patient 001.xml」である。まず、設定データ132から当該fieldTypeのtokenizerを取得する。fileNameフィールドのtokenizerはWhitespaceTokenizerである。このtokenizerのKeyword分割ロジックは様々な実装が考えられるが、本実施形態では、空白またはピリオドでKeyword分割する実装であるとする。WhitespaceTokenizerで前述した文字列をKeyword分割すると、「patient」「001」「xml」と分割される。この文字列をインデクスに登録する。「patient」をインデクス登録する際は、Keyword501に「patient」を格納する。DocID502には当該ファイルを一意に識別可能な数値を割り当てられる。また、Position505には、当該Keywordの、他のKeywordに対する相対位置が格納される。相対位置は、対象の文字列をKeyword分割した際の出現した順序を表す。「patient」の場合は「1」が格納される。このようにして、XMLデータ131に格納されているすべてのXMLファイルに対して非xmlフィールドのインデクス生成を行う。また、図５Ｃに示すように、DocID毎に非xmlフィールドを格納したデータを生成する。

ステップ803では、インデクス生成プログラム122は、xmlフィールドのインデクス生成を行う。当該xmlフィールドのインデクス生成処理の詳細については、図９のフローチャートを用いて後述する。

＜xmlフィールドのインデクス生成処理の詳細＞
図９は、図８のS803（xmlフィールドのインデクス生成処理）の詳細について説明するためのフローチャートである。

ステップ901では、インデクス生成プログラム122は、Tableデータ141から未処理のレコードを読み込む。例えば、図４における1行目のデータに対してインデクス生成を行う場合を考える。

ステップ902では、インデクス生成プログラム122は、ColumnID1〜3のデータをKeyword分割する。まず、設定データ132からxmlフィールドのtokenizerを取得する。xmlフィールドのtokenizerはWhitespaceTokenizerである。WhitespaceTokenizerのKeyword分割ロジックは前述の場合と同様とする。ColumnID1の文字列「xmlRoot patient id xmlLeaf」をKeyword分割すると、「xmlRoot」「patient」「id」「xmlLeaf」と分割される。さらに、ColumnID2の文字列「attribute」とColumnID3の文字列「001」をKeyword分割すると、それぞれ、「attribute」と「001」となる。

ステップ903では、インデクス生成プログラム122は、分割されたKeyword群から未処理のKeywordを1つ選択する。例えば「xmlRoot」を選択したとする。

ステップ904では、インデクス生成プログラム122は、当該Keywordにおける、DocID、RowID、ColumnID、Positionをインデクスデータのレコードとして登録する。Keywordが「xmlRoot」の場合は、Keyword501に「xmlRoot」、DocID502に「1」、RowID503に「1」、ColumnID504に「1」、Position505に「1」を格納する。

ステップ905では、インデクス生成プログラム122は、ステップ902で得られたKeywordがすべて処理されたか否かを判定する。真の場合、処理はステップ906に進み、偽の場合、処理はステップ903に戻る。

ステップ906では、インデクス生成プログラム122は、Tableデータ141における全レコードを処理したか否かを判定する。真の場合、処理は終了する。偽の場合、処理はステップ902に戻る。

＜検索処理＞
図１０は、検索プログラム123が実行する検索処理を説明するためのフローチャートである。検索処理では、図５のインデクスデータをもとに、図６のような検索画面で入力された検索クエリ（検索条件を表す文字列）に該当するXMLファイルを検索結果として表示する。

検索画面において検索クエリが入力され検索ボタンが押下されると、検索処理が開始する。以下、検索クエリが「xml:(<"xmlRoot patient homeTown city xmlLeaf"> <element> <"New York">) AND fileName:(patient xml)」であった場合で説明する。

ステップ1001では、検索プログラム123は、記憶装置130から、設定データ132、インデクスデータ133を読み込む。

ステップ1002では、検索プログラム123は、検索クエリを解析し、フィールド単位に分割する。本実施形態では、分割されたクエリをフィールドクエリと呼ぶ。上記の例では、「xml:(<"xmlRoot patient homeTown city xmlLeaf"> <element> <"New York">)」と「fileName:(patient xml)」に分割される。この際、各フィールドクエリ間の論理演算子の位置はデータメモリ140に記憶される。

ステップ1003では、検索プログラム123は、未処理のフィールドクエリを1つ選択する。
ステップ1004では、検索プログラム123は、ステップ1003で選択されたフィールドクエリがxmlフィールドのクエリか否かを判定する。真の場合はステップ1007に進み、偽の場合はステップ1005に進む。

ステップ1005では、検索プログラム123は、非xmlフィールドのフィールドクエリを解析し、Keyword単位に分割する。「fileName:(patient xml)」の場合で説明する。この場合、フィールド名はfileNameである。設定データ132から、fieldTypeのname属性が「fileName」のtokenizerを読み込む。この場合、WhitespaceTokenizerである。そして、WhitespaceTokenizerで、当該フィールドのフィールド値をKeyword分割する。「patient xml」に適用すると、それは、「patient」と「xml」に分割される。

ステップ1006では、検索プログラム123は、ステップ1005で得られたKeywordを基に該当する文書を絞り込む。具体的には、インデクスデータ133のfileNameフィールドのテーブル（図５B）を参照し、ステップ1005で得られたKeywordの「patient」と「xml」をともに含むDocIDをリストアップする。リストアップされたDocIDはデータメモリ140に記憶しておく。

ステップ1007では、検索プログラム123は、xmlフィールドのフィールドクエリを解析し、Column単位に分割する。「xml:(<"xmlRoot patient homeTown city xmlLeaf"> <element> <"New York">)」の場合で説明する。設定データ132からfieldTypeのname属性が「xml」のcolumnTokenizerを読み込む。この場合、TableTokenizerである。そして、TableTokenizerで、当該xmlフィールドのフィールド値をKeyword分割する。TableTokenizerは、「< >」で囲まれた文字列を認識し、出現した順にColumnIDを割り振る処理を行う機能を持つ。「xml:(<"xmlRoot patient homeTown city xmlLeaf"> <element> <"New York">)」に適用した場合、「"xmlRoot patient homeTown city xmlLeaf"」がColumnID1、「element」がColumnID2、「"New York"」がColumnID3となる。本実施形態では、xmlフィールドのフィールドクエリは、3つのColumnで構成される。

ステップ1008では、検索プログラム123は、ステップ1007で得られた各ColumnIDの文字列を解析し、Keyword単位に分割する。設定データ132から、fieldTypeのname属性が「xml」のtokenizerを読み込む。この場合はWhitespaceTokenizerである。そして、WhitespaceTokenizerで、当該フィールドのフィールド値をKeyword分割する。「"xmlRoot patient homeTown city xmlLeaf"」に適用すると、「xmlRoot」、「patient」、「homeTown」、「city」、「xmlLeaf」に分割される。なお、この場合は文字列全体が「" "」で囲まれているためフレーズ検索となる。フレーズ検索は、指定したKeywordが連続して現れる文書を検索する機能である。この場合、前述した5個のKeywordが連続して現れる文書が検索される。

ステップ1009では、検索プログラム123は、ステップ1008で得られたKeywordを基に該当する文書を絞り込む。ステップ1009の詳細は、図１１を参照して後述する。

ステップ1010では、検索プログラム123は、全フィールドクエリを処理したか否かを判定する。真の場合、処理はステップ1011に進み、偽の場合、処理はステップ1003に進む。

ステップ1011では、検索プログラム123は、各フィールドクエリに該当する文書を、論理条件を考慮して絞り込む。例えば、検索クエリが「xml:(<"xmlRoot patient homeTown city xmlLeaf"> <element> <"New York">) AND fileName:(patient xml)」であった場合、「xml:(<"xmlRoot patient homeTown city xmlLeaf"> <element> <"New York">)」に該当するDocIDと、「fileName:(patient xml)」に該当するDocIDを、論理条件「AND」で絞り込む。

ステップ1012では、検索プログラム123は、ステップ1011で絞り込まれた該当文書を検索結果として表示画面上（検索結果604）に表示する。この際、検索結果数や、各文書のフィールド値を表示してもよい。

＜文書絞り込み処理の詳細＞
図１１は、検索プログラム123が実行する検索処理内のxmlフィールドにおける文書の絞り込み処理の詳細を説明するためのフローチャートである。

ステップ1101では、検索プログラム123は、ステップ1008で得られたKeywordの中から未処理のKeywordを1つ選択する。

ステップ1102では、検索プログラム123は、当該KeywordのColumnIDが一致するDocIDとRowIDの組合せをリストアップする。例えば、Keywordが「id」の場合、ColumnIDは「1」である。インデクスデータ133において、Keywordが「id」かつColumnIDが「1」であるDocIDとRowIDの組合せはそれぞれ「1」と「1」の場合((1,1)と表記することがある)が該当する。

ステップ1103では、検索プログラム123は、ステップ1008で得られた全Keywordを処理したか否かを判定する。真ならば、処理はステップ1104に進み、偽ならば、処理はステップ1101に進む。

ステップ1104では、検索プログラム123は、フィールドクエリがフレーズクエリであった場合の絞り込み処理である。この場合、ステップ1008で得られた全Keywordに対して、インデクスデータ133のPosition405の整合性をチェックし、DocIDとRowIDの組合せを絞り込む。例えば、フィールドクエリにおいて「"xmlRoot patient homeTown city xmlLeaf"」の部分はフレーズクエリであるため、各KeywordのPositionが順序通りである必要がある。インデクスデータ133において、DocIDとRowIDの組合せが(1,5)の場合に、各KeywordのPositionは、「xmlRoot」が「1」、「patient」が「2」、「homeTown」が「3」、「city」が「4」、「xmlLeaf」が「5」である。この場合、各KeywordのPositionが順序通りであるため条件に適合していると判定される。

ステップ1105では、検索プログラム123は、ステップ1008で得られた全Keywordと、ステップ1102（フレーズクエリの場合はステップ1104）で得られたDocIDとRowIDの組合せを照合し、全Keywordで、DocIDとRowIDの組合せが同一となるDocIDをリストアップする。例えば、前述したフィールドクエリにおけるKeywordはすべて、DocIDとRowIDの組合せが(1,1)となる場合がある。そのため、DocIDが「1」の場合はリストアップされる。リストアップされたDocIDはデータメモリ140に記憶しておく。

＜まとめ＞
（i）本発明の実施形態では、階層構造データ（XMLデータ）を解析し、階層構造データを検索する際に用いられるインデクスデータを生成している。階層構造データは、各階層において、要素及び／又は属性を表す少なくとも１つの文字列と、当該文字列の要素値或いは属性値とによって構成されるパス情報を有している。このとき、まず、階層構造データの各階層で定義されるパス情報に対して解析ツール（例えば、図３で示される設定データ）を適用し、階層内及び階層間における、繋がりとして意味のある複数の文字列の文字列グループの識別情報（RowID）と、各文字列グループにおける要素又は属性とその要素値又は属性値との対応関係を示す表構造データ（図４）に、階層構造データを変換する。そして、表構造データを参照し、文字列、要素値、及び属性値の表構造データにおける位置の情報（Position）と、文字列グループの識別情報（RowID）と、を含む階層構造データについてのインデクスデータ（図５Ａ）を生成する。このインデクスデータを用いることにより、階層構造データについて、高速に、かつパスを様々な形式で指定した検索が可能となり、さらに、属性検索との複合検索も可能になる。

また、少なくとも１つの文字列グループの構成文字列（例えば、図４のpatient name family）に完全一致パスであることを示す２つの文字列（例えば、xmlRootとxmlLeaf）を構成文字列の先頭と末尾に含める（言い換えると、階層の先頭と終端に、それぞれ先頭識別子と終端識別子を付与する）ようにして表構造データを生成する。これにより、階層構造データの検索時に２つの文字列で挟まれる複数の文字列が完全一致した場合に検索結果として抽出されるように設定できるようになる。なお、図４においては、全ての文字列グループにxmlRootとxmlLeafが付与されているが、ユーザの指示により適宜付与しない文字列が存在しても良い。付与されない場合には、完全一致ではなく部分一致でも検索結果として抽出されることになる。つまり、完全一致パスと部分一致パスとを区別したい場合にxmlRootとxmlLeafを付与すれば良い。

検索対象のファイルには、階層構造データ（XMLデータ）と非階層構造データ（非XMLデータ）が含まれている。非階層構造データについては、表構造データに変換することない。ただし、階層構造データのインデクスデータとの対応が取れるように、非階層構造データについてのインデクスデータが生成される。これにより、非階層構造データに基づく検索も可能となる。また、階層構造データによる検索結果と併せることにより、非階層構造データと階層構造データとの対応を取りながら、検索結果をより的確に絞り込むことができるようになる。

生成されたインデクスデータを用いて検索処理を実行する場合、それぞれ検索文字列を含む複数のフィールドがAND及び／又はORで区切られて構成される検索クエリを解析して、当該検索クエリをフィールド単位で分割する。そして、フィールド単位の検索文字列に対して解析ツール（図３の設定データ）を適用してキーワードに分割する。さらに、キーワードと階層構造データについてのインデクスデータとを比較することにより、検索結果を抽出して出力する。このようにすることにより、全文検索エンジンにおいて、XMLを、XMLタグの階層構造を指定して検索が可能となる。また、ファイルの属性データとXML内の階層構造のデータの統合検索が可能となる。また、XML以外のファイルと共に、XMLを統合的に検索可能となる。また、さらに、XMLの階層構造を指定する際、様々な指定方法が可能となる。

本実施形態では、フレーズクエリを用いた検索にも対応している。この場合、フィールドにおける各キーワードの配置順序を示す相対的位置と、インデクスデータの文字列の前記表構造データにおける位置の情報との整合性をチェックして検索結果を抽出する。これにより、階層構造データ（XMLデータ）用のフィールドを通常のフィールドと等価に扱うことができるため、論理演算子を使用することによりこれらの複合検索も可能である。

なお、フィールド単位のクエリを実行する前に、当該クエリが、階層構造データに関するクエリであるか、非階層構造データに関するクエリであるか、を判断する。そして、非階層構造データについてのクエリの処理と、階層構造データについてのクエリの処理は別々に実行され、階層構造データについてのインデクスデータを用いた検索結果と、非階層構造データについてのインデクスデータを用いた検索結果とが統合され、最終的な検索結果として生成される。これにより、階層構造データを、階層構造を考慮して検索可能となる。また、どのような構造のXMLでも同様に処理可能であり、すなわちXMLスキーマに依存せず様々な形式のXMLを検索可能である。また、階層を指定する際、フレーズ検索を利用することにより、階層の順序を考慮して検索することも可能である。フレーズ検索を利用しなければ、階層の順序を考慮しないで検索することも当然可能である。

（ii）本発明は、実施形態そのままに限定されるものではなく、実施段階では、その要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

また、実施形態で示された各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上記各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能等を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録或いは記憶装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録或いは記憶媒体に格納することができる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

10…XMLデータ処理装置
100…中央処理装置（プロセッサ）
110…入出力装置
111…表示装置
112…キーボード
113…ポインティングデバイス（マウス）
120…プログラムメモリ
121…Tableデータ生成プログラム
122…インデクス生成プログラム
123…検索プログラム
130…記憶装置
131…XMLデータ
132…設定データ
133…インデクスデータ
140…データメモリ
141…Tableデータ

Claims (14)

1. 階層構造データを解析し、階層構造データを検索する際に用いられるインデクスデータを生成する電子データ処理装置であって、
   前記階層構造データを解析するための解析ツールと、前記インデクスデータを生成するためのプログラムを含む、管理情報を格納する記憶装置と、
   前記解析ツールを用いて前記階層構造データを解析し、前記プログラムを実行して前記インデクスデータを生成するプロセッサと、を有し、
   前記階層構造データは、各階層において、要素及び／又は属性を表す少なくとも１つの文字列と、当該文字列の要素値或いは属性値とによって構成されるパス情報を有し、
   前記プロセッサは、
   前記階層構造データの各階層で定義される前記パス情報に対して前記解析ツールを適用し、階層内及び階層間における、繋がりとして意味のある複数の文字列の文字列グループの識別情報と、各文字列グループにおける前記要素又は前記属性とその要素値又は属性値との対応関係を示す表構造データに、前記階層構造データを変換し、
   前記表構造データを参照し、前記文字列、前記要素値、及び前記属性値の前記表構造データにおける位置の情報と、前記文字列グループの識別情報と、を含む階層構造データについてのインデクスデータを生成することを特徴とする電子データ処理装置。
2. 請求項１において、
   前記プロセッサは、少なくとも１つの前記文字列グループの構成文字列に完全一致パスであることを示す２つの文字列を含め、階層構造データの検索時に前記２つの文字列で挟まれる複数の文字列が完全一致した場合に検索結果として抽出されるように設定することにより、前記表構造データを生成することを特徴とする電子データ処理装置。
3. 請求項１において、
   前記階層構造データと非階層構造データとによって１つのファイルが構成されており、
   前記プロセッサは、前記非階層構造データについては、前記表構造データに変換することなく、前記階層構造データのインデクスデータとの対応が取れるように、非階層構造データについてのインデクスデータを生成することを特徴とする電子データ処理装置。
4. 請求項２において、
   前記階層構造データはXMLデータであり、前記２つの文字列はxmlRoot及びxmlLeafであることを特徴とする電子データ処理装置。
5. 請求項３において、
   前記プロセッサは、さらに、
   入力された、それぞれ検索文字列を含む複数のフィールドがAND及び／又はORで区切られて構成される検索クエリを解析して、当該検索クエリをフィールド単位で分割し、
   前記フィールド単位の検索文字列に対して前記解析ツールを適用してキーワードに分割し、
   前記キーワードと前記階層構造データについてのインデクスデータとを比較することにより、検索結果を抽出して出力することを特徴とする電子データ処理装置。
6. 請求項５において、
   前記検索クエリはフレーズクエリを含み、
   前記プロセッサは、前記フィールドにおける各キーワードの配置順序を示す相対的位置と、前記インデクスデータの文字列の前記表構造データにおける位置の情報との整合性をチェックして検索結果を抽出することを特徴とする電子データ処理装置。
7. 請求項５において、
   前記プロセッサは、
   前記検索クエリを分割して得られた各フィールドのクエリが、階層構造データに関するクエリであるか、非階層構造データに関するクエリであるか、を判断し、
   前記階層構造データについてのクエリとは別に、前記非階層構造データについてのクエリを前記非階層構造データについてのインデクスデータを用いて検索結果を抽出し、
   前記階層構造データについてのインデクスデータを用いた検索結果と、前記非階層構造データについてのインデクスデータを用いた検索結果とを統合して最終的な検索結果を生成することを特徴とする電子データ処理装置。
8. 階層構造データを解析し、階層構造データを検索する際に用いられるインデクスデータを生成する電子データ処理方法であって、
   前記階層構造データは、各階層において、要素及び／又は属性を表す少なくとも１つの文字列と、当該文字列の要素値或いは属性値とによって構成されるパス情報を有し、
   プロセッサが、前記階層構造データを解析するための解析ツールと、前記インデクスデータを生成するためのプログラムを含む、管理情報を格納する記憶装置から、前記解析ツールを読み出し、当該解析ツールを用いて前記階層構造データを解析するステップと、
   前記プロセッサが、前記プログラムを実行して前記インデクスデータを生成するステップと、を有し、
   前記階層構造データを解析するステップは、前記プロセッサが、前記階層構造データの各階層で定義される前記パス情報に対して前記解析ツールを適用し、階層内及び階層間における、繋がりとして意味のある複数の文字列の文字列グループの識別情報と、各文字列グループにおける前記要素又は前記属性とその要素値又は属性値との対応関係を示す表構造データに、前記階層構造データを変換するステップを含み、
   前記インデクスデータを生成するステップは、前記プロセッサが、前記表構造データを参照し、前記文字列、前記要素値、及び前記属性値の前記表構造データにおける位置の情報と、前記文字列グループの識別情報と、を含む階層構造データについてのインデクスデータを生成するステップを含むことを特徴とする電子データ処理方法。
9. 請求項８において、
   前記階層構造データを変換するステップにおいて、前記プロセッサは、少なくとも１つの前記文字列グループの構成文字列に完全一致パスであることを示す２つの文字列を含め、階層構造データの検索時に前記２つの文字列で挟まれる複数の文字列が完全一致した場合に検索結果として抽出されるように設定することにより、前記表構造データを生成することを特徴とする電子データ処理方法。
10. 請求項８において、
    前記階層構造データと非階層構造データとによって１つのファイルが構成されており、
    前記インデクスデータを生成するステップは、さらに、前記プロセッサが、前記非階層構造データについては、前記表構造データに変換することなく、前記階層構造データのインデクスデータとの対応が取れるように、非階層構造データについてのインデクスデータを生成するステップを含むことを特徴とする電子データ処理方法。
11. 請求項９において、
    前記階層構造データはXMLデータであり、前記２つの文字列はxmlRoot及びxmlLeafであることを特徴とする電子データ処理方法。
12. 請求項１０において、さらに、
    前記プロセッサが、入力された、それぞれ検索文字列を含む複数のフィールドがAND及び／又はORで区切られて構成される検索クエリを解析して、当該検索クエリをフィールド単位で分割するステップと、
    前記プロセッサが、前記フィールド単位の検索文字列に対して前記解析ツールを適用してキーワードに分割するステップと、
    前記プロセッサが、前記キーワードと前記階層構造データについてのインデクスデータとを比較することにより、検索結果を抽出して出力するステップと、
    を有することを特徴とする電子データ処理方法。
13. 請求項１２において、
    前記検索クエリはフレーズクエリを含み、
    前記検索結果を抽出して出力するステップにおいて、前記プロセッサは、前記フィールドにおける各キーワードの配置順序を示す相対的位置と、前記インデクスデータの文字列の前記表構造データにおける位置の情報との整合性をチェックして検索結果を抽出することを特徴とする電子データ処理方法。
14. 請求項１２において、さらに、
    前記プロセッサが、前記検索クエリを分割して得られた各フィールドのクエリが、階層構造データに関するクエリであるか、非階層構造データに関するクエリであるか、を判断するステップと、
    前記プロセッサが、前記階層構造データについてのクエリとは別に、前記非階層構造データについてのクエリを前記非階層構造データについてのインデクスデータを用いて検索結果を抽出するテップと、
    前記プロセッサが、前記階層構造データについてのインデクスデータを用いた検索結果と、前記非階層構造データについてのインデクスデータを用いた検索結果とを統合して最終的な検索結果を生成するステップと、
    を有することを特徴とする電子データ処理方法。

Images