JP2008059557A - データベースインデクシング、サーチング、及びデータ検索のシステム及び方法 - Google Patents

Abstract

【課題】本発明はテーブルアクセスを減少するデータベースを検索する方法を提供する。
【解決手段】データベースを検索する方法であって、上記データベースはコンピュータが読み込み可能な装置に記憶された複数のレコードを備え、上記複数のレコードのそれぞれは１以上の複数のドキュメントを備え、インデックスファイルは複数の装置識別子を備え、上記装置識別子のそれぞれは複数のパラメータ識別子を備え、上記パラメータ識別子のそれぞれはリアルタイム値を有し、上記方法は、上記装置識別子に関連される装置を選択する段階と、上記選択された装置に関連されるパラメータ識別子を選択する段階と、上記データベースの検索クライテリアを備える検索クエリを受信する段階と、上記検索クエリに応答する上記データベースを検索する段階と、上記検索クライテリアを満足するレコードを表示する段階とを備えるデータベースを検索する方法。
【選択図】図２

Description

本発明は、一般に電子データ記憶と検索に関する。更に詳しくは、本発明は、所望の検索及びデータ検索を達成するために、検索インデックスの作成、組織化、維持、及び使用を含むインデクシング、サーチング、及びデータ検索技術に関する。さらに、本発明は、また装置パラメータ情報分野のサーチング及びナビゲーションの方法に関する。

人間の知識の様々な分野の途方もない量の情報は、コンピュータメモリシステムに収集され、保存される。コンピュータメモリシステムが公共に利用可能なデータ通信ネットワークに更にリンクされるに従い、公共あるいは個人の使用のために情報のサーチング及び検索するためのシステム及び方法を開発する必要性が増している。

情報は、異なるデータ形式のフォームで記録される可能性があり、そして情報サーチと検索との関連で、ダイナミックデータとスタティックデータとを識別することは有用である。ダイナミックデータは、しばしば及び連続的に変化するデータであり、そのため有効なデータの１組はリアルタイムデータを示し、一方スタティックデータは、ユーザの要求と同時に、あるいは予め設定された時間間隔の後にのみ変化する。例えば、株価のような経済データ、あるいは気象データは、非常に速く変化するため、それゆえダイナミックである。一方、本及びドキュメントのアーカイブ記録は、通常永続的であり、スタティックデータである。データの不安定性の概念は、情報がどのくらいの期間有効かに関連する。データの不安定性は、情報がサーチされ及び検索されるべき方法に、なんらかの関係を有する。大量のデータは、検索を容易にするための何らかの構造を必要とするが、そのような構造を構築する時間は、データが有効である期間より長くてはならない。構造を構築するコストは、データ量に依存し、それゆえ情報を検索するためのデータ構造の構築は、データ量と不安定性を考慮に入れなければならない。収集される情報は、データベースに記録され、これらは構築されているか、または構築されてない可能性がある。さらに、データベースは、画像、ビデオ、音、及びフォーマットされるか注釈付きのテキストを含む複合ドキュメントを具備する数種類のドキュメントを具備する可能性がある。特に構築されたデータベースは、データをサーチし検索するのを容易にするためにインデックスが一般に備えられる。

ドキュメントの大きなプールから関連するドキュメントを見つける技術は、さらに望まれている。この技術を提供するプログラムは、検索エンジンとして一般に知られている。検索エンジンは、一般的にドキュメントのプールを処理し、ワードのインデックスを構築する。ユーザは検索要求あるいはクエリを入力することができ、特定のワードを具備するドキュメントのリストを検索する。検索エンジンは、インデックスを処理し、要求を満足するドキュメントのリストを戻す。検索エンジンは、インターネット上のどのウェブサイトが、関連する内容を具備するかについて決定するために、しばしば使用される。検索エンジンは、イントラネット、ファイルサーバ、及びデータベースからの情報にアクセスするためにも使用される。電子的に利用できるデータの量が膨大であれば、検索エンジンはドキュメントの大きなプールから関連するドキュメントを見つける構造としてさらに重要になる。

効率は、検索エンジン技術において非常に重要である。ドキュメントの関連するプールが比較的小さいとき、能率の悪いインデクシング及び／あるいは検索の処理が目立たない可能性がある一方で、ドキュメントのプールが比較的大きくなるとき、非効率性は過度のインデックス及び過度の検索処理時間にすぐに至る。効率は、例えば複雑な処理クエリあるいは自然言語処理クエリのようなフルテキストインデックスの他態様でも重要と考慮される。検索エンジンは、一般的に、検索要求を複数のサブクエリに分割することにより自然言語検索を実施する。従って、もし検索アルゴリズムの効率が悪ければ、応答時間は深刻に低下する可能性がある。

検索要求は、一般的に、例えばＡＮＤ、ＯＲ、あるいはＮＯＴのような、１以上の論理演算子、および、例えばワードＢの１０ワード内のワードＡのようなそれに近い制限で分割される１以上のワードのフォームになる。検索エンジンは、どのドキュメントが要求を満足するかについて決定し、そのようなドキュメントのリストを返す。

多数のドキュメントが、インデックスされたドキュメントのプールあるいはセットが大きい場合に、検索要求を満足する可能性がある。どのドキュメントが関連する内容を最も含んでいる可能性があるかについて、ユーザが決定するのを援助するために、多くの検索エンジンは、検索要求を満足するそれぞれのドキュメントに「関連」ランキングを提供する。関連ランキングは、特定の検索要求を考慮してドキュメントの重要性についての検索エンジンにより提供される評価である。これらの関連性の順にドキュメントをランク付けし、ユーザに提供する技術は、検索要求を満足する多くのドキュメントが実際に関連するかをユーザが決定するのに費やさなければならない時間を最小にするために、更に重要になる。関連性によりドキュメントにランク付けすることは、検索エンジンに更なる複雑さを追加し、別の潜在的効率の考慮が必要となることを示す。理想的には、関連性の決定は、検索エンジンの全体的な応答時間を深刻に増加させない。

検索エンジンの効率を増加するための最高の機構のうちの１つは、周辺の入出力（Ｉ／Ｏ）機能と、メモリ内のテーブルアクセスとを最小にすることである。フルテキストインデックスは、一般に、相互参照情報を具備する情報のいくつかのテーブルで構成され、検索要求の間、多くの異なるテーブルは、特定のワードがどんなドキュメントに位置するかを決定することを含む、付属する決定を行うためにアクセスされる。フルテキストインデックスは非常に大きいものである可能性があり、数百メガバイト以上ものスペースを必要とする可能性がある。そのサイズのため、フルテキストインデックスの全体は、一般的にコンピュータのメモリに適合せず、テーブルインデックスアクセスは、ディスクへの少なくとも１つのＩ／Ｏ機能に結果としてなる可能性があり、アクセス手順によっては、複数のＩ／Ｏに結果としてなる可能性がある。Ｉ／Ｏ機能は、とても時間のかかる処理である。さらに、ワードの共通性に従い、１回の検索要求は、何十万ものテーブルアクセスを必要とする可能性がある。Ｉ／Ｏ機能を除くか、減少することは、応答時間を有効に減少することができるので、テーブルアクセスを減少することは有益である。テーブルアクセスを減少するための１つの機構は、ワード情報、つまり情報それ自体が別のドキュメントレベルテーブルにアクセスする必要なくドキュメントレベルの決定がなされることを許容することを記憶することである。

本発明の第１の態様によれば、データベースを検索する方法が提供され、上記データベースはコンピュータが読み込み可能な装置に記憶される複数のレコードを備え、複数のレコードのそれぞれは１以上の複数のドキュメントを備え、インデックスファイルは複数の装置識別子を備え、複数の装置識別子のそれぞれはパラメータ識別子を備え、パラメータ識別子のそれぞれはリアルタイム値を有し、上記方法は装置識別子に関連する装置を選択する段階と、データベースの検索クライテリアを有する検索クエリを受信する段階と、検索クエリに対応するデータベースを検索する段階と、検索クライテリアを満足するレコードを表示する段階とを備えるものとする。

本発明の第２の態様によれば、データベースを備えるシステムが提供され、上記データベースはコンピュータが読み込み可能な装置に記憶される複数のレコードと、複数のレコードのそれぞれは１以上の複数のドキュメントを備え、インデックスファイルは複数の装置識別子を備え、それぞれの装置識別子は複数のパラメータ識別子を備え、パラメータ識別子のそれぞれはリアルタイム値を有するものとする。

本発明のさらに他の目的は、単に実例として、本発明を実行することを意図するベストモードの１つであるこの発明の好ましい実施形態が示され及び記載されていることが以下の記載から当業者には明確である。理解されるように、本発明はこの発明から逸脱することなく、全て他の異なる明確な態様を可能とする。図面と詳細な説明は、自然に図示され、限定として見なされるものではない。

この発明の更なる目的は、それに貢献している更なる特徴と、そこから生じる利点と共に、全体を通して対応する部品を示す参照番号のように添付の図面に示され、かつ以下の図面と併せて読まれる、本発明の一実施形態の以下の記載から明確である。
これらと本発明の更なる実施形態は、ここで図示された実施形態が記載される以下の詳細な説明を参照することにより、より理解される可能性がある。

この詳細な説明を通して、示される実施形態と例題は、本発明の装置および方法に対する制限としてよりむしろ、例題として考慮されなければならない。

本発明は、データがデータベースの範囲内のレコードに記憶されるデータ記録とデータ検索のためのシステムと方法を提供し、所望のレコードは、検索クライテリアを適当なレコードに配置するインデックスファイルの検索を実行することにより特定され、および／あるいは選択される。上記全体的な組織、構造、及びデータベースの使用は、関係するハードウェア及びソフトウェア操作環境により大いに変化する可能性がある。

ここに使用されるように、データベースは、ドキュメントと称されるデータファイルの収集を参照し、任意のインデックスファイル及び検索に使用される他のサポートファイル、ドキュメントをアクセスし及び維持する。ドキュメントは、それ自身で他のドキュメントを具備する指定されたフォーマット（例えばＨＴＭＬ、テキスト、ＪＰＥＧ、ＢＭＰ、その他）またはフォルダまたはディレクトリの個々のファイルである可能性がある。データベースの様々なドキュメントの関係は、データベース自体の範囲内で、または、外部的に定められる可能性がある。データベースは、コンピュータで読み取り可能メディアに格納される。

ここに使用されるように、パラメータは装置の情報を参照する。パラメータはアドレス自体である可能性があり、あるいは、それはアドレスを計算するか、決定するのに使用されるデータである可能性がある。

［本発明のインデックスファイル構造］
図１を参照すると、データベースのインデックスファイル１の１実施形態の構造が示される。上記インデックスファイル１は、複数の装置識別子とリアルタイム値を有する複数のパラメータ識別子を備える。当然のことながら、図１のパラメータ識別子の値は、任意である。

図１で示す例において、装置識別子のそれぞれは、例えば製造工場の組み立て装置のような特定装置に関連する。それぞれの装置識別子は、例えばMODE_BLK.ACTUAL、MODE_BLK.PERMITTED、及びMODE_BLK.TARGET等のように、少なくとも１つのパラメータ識別子を有する。例えば製造工程の異なる段階の間のように、上記値は時間を超えて変化する可能性があるので、パラメータ識別子のそれぞれは１組のリアルタイム値を有する。

［本発明の方法］
本発明は、その用途と同様に、インデックスファイルの実際の構造を目的として、インデックスファイルが実際作成される方法は重要ではない。これらのファイルは、その中で説明されるように後の検索のために、望ましい関係を生じるために、有名なプログラムアルゴリズム、所有者方法、あるいはその組合せを使用して作成される可能性がある。

例えば、パラメータ識別子のリアルタイム値は、それぞれの値の完全性を確実にするために、設計された様々なエラーチェックとフォーマットアルゴリズムで、手動データ入力、一連のデータファイルの処理、あるいはその結合により作成される可能性がある。同様に、一旦リアルタイム値のレコードが作成されるならば、インデックスファイルは、リアルタイム値の記録、様々なソート、結合、確認、フォーマット化するアルゴリズム等の連続した処理により作成される可能性がある。

リアルタイム値のレコードは、リアルタイムにあるいは様々な更新期間で維持される可能性があり、そしてインデックスファイルと他のファイルは、更新される値との同期を維持するのに必要とされるように、同様に更新され、再生される可能性がある。他のファイルは、例えばドキュメントレイアウトを定義するテンプレートファイル、予想される検索クエリを適当なレコードに配置する汎用クエリインデックスファイル、特定のボリュームのための対応するレコードによる関連するメタデータセット付きメタファイル、全データベースのための対応するレコード付きのメタデータセット、等を具備する。

一旦作成されると、インデックスファイルは、検索クライテリアを満足する対応するレコードに検索クライテリアを配置するインデックスファイルの検索を導くことによりレコードを識別し及び／あるいは選択するために使用される。本発明の典型的な使用において、検索者あるいはエンドユーザは、検索クライテリアをここに記載される上記コンセプトを実施するソフトウェアシステムへ提示し、検索クライテリアに適合しそれとともに関連する特徴を有するパラメータとその個別値を識別することを目的とする。上記データベースは次いで検索され、上記検索クライテリアに対応するレコードは識別され、検索者に示される。多数のクライテリアは、最初のクエリで指定される可能性があり、その場合には、下位クエリが実施される可能性があり、例えばＡＮＤ、ＯＲ、その他のような論理演算は、完全な検索クライテリアを満足するレコードを表現する最終結果を得るために、それぞれの下位クエリから特定されたレコードの結果として生じる一組上で実施される可能性がある。

インデックスファイルが検索者によりクエリに応答して使用される可能性がある方法の実際的な例として、図２を参照して、この例は検索者が例えば組み立て装置のような特定の装置のクエリを開始することを想定している。その後、上記検索者は、例えばMODE_BLK.TARGET等のような組み立て装置のパラメータのためのクエリを更に開始する。本発明によれば、ソース、タイプ、あるいはクエリと関連する他の情報に基づき、検索アルゴリズムは、検索するためのインデックスとしてテキストインデックスファイルを特定する。検索クエリは組み立て装置とそのパラメータMODE_BLK.TARGETのためであるので、パラメータのリアルタイム値が配置される。これは、例えばパラメータの既知の固定長と文字列の既知の照合に基づく計算を使用することにより単一ディスク検索機能だけのコストで、実現できる可能性がある。

図２を参照すると、フローチャートが本発明によるクエリに基づき、レコードを識別しかつ評価するために使用される典型的段階の図が示される。示される段階は、検索者によりクエリあるいは一組のクエリに応答してレコードを獲得するために使用される。上記処理は、ステップ２００から開始する。ステップ２０１において、検索者は例えば組み立て装置のような検索者は特定の装置を選択する。その後、ステップ２０２において、検索者は選択された装置に関連するパラメータを選択する。例えば、クエリ形式は、例えばMODE_BLK.ACTUAL、MODE_BLK.PERMITTED、and/or MODE_BLK.TARGETのようなパラメータの一組に基づくクエリである可能性がある。ステップ２０２とステップ２０３において、クエリの性質とソースに基づいて、上記クエリはデータベース２０５に導かれる。ステップ２０７においてユーザにより絶えず更新されるデータベース２０６のレコードは、パラメータのリアルタイム値を具備する。検索のために適切なインデックスファイル１は、次いでテキストインデックスファイル、メタデータインデックスファイル、プロパティインデックスファイル、あるいはそれぞれの一般のクエリインデックスファイルである可能性がある。

一旦検索するために適切なインデックスファイルが特定されるならば、ステップ２０５において、上記選択された装置のパラメータのリアルタイム値は検索者に表示される。上記検索者は、同様に選択された装置のパラメータの履歴の値を見るためのオプションを有する可能性がある。さらに、上記検索者は、スクリーン上に表示されるパラメータを活性化することにより、１つのパラメータから選択された装置の別のパラメータのナビゲートでもある可能性がある。

ステップ２０５において、上記クエリが満足されたかどうか、あるいは上記クエリが部分的に満足されただけだったかどうかが決定される。部分的に満足されるだけだったクエリが存在するならば、プロセスはステップ２０１まで進行し、そこで、上記検索者は別の装置あるいは別のパラメータを選択する。クエリが１以上の装置のために必要とされる環境において、上記検索者は複数の装置とそれらのそれぞれのパラメータを検索するためのオプションを有する可能性があり、それゆえ全体的な検索結果が１スクリーンで同時に見られる可能性がある。もし上記クエリが完全に満たされるならば、上記検索者は装置パラメータウインドウを見るのを選択する可能性があり、そして選択されたアクション、オブジェクト、及び／あるいは特定の用語を表示する。

本発明は、また検索者が構成された装置を検索するのを許容し、新しい処理プラントの委任の間、装置が正しく構成されたことを確認することもできる可能性がある。

従って、上記レコードは例えばＨＴＭＬあるいはＸＭＬのような広く許容されたデータフォーマットに保存され、従ってＨＴＭＬあるいはＸＭＬ互換の環境において能率的に表現される。つまり、上記レコードは、それと関連するデータをフォーマット化する完全な表示を有し、そのため一旦検索クライテリアを満たすレコードが特定され、位置するならば、それらは検索される可能性があり、ダイナミックなページの創造、フォーマット化等の必要なしに表示装置上で検索者に提示される可能性がある。

上記レコードのそれぞれは、マスタードキュメントをそれと関連付け、様々なスタイル、サイズ、フォーマットのそれぞれのレコードと関連する様々なビュードキュメントを任意に有する可能性がある。選択されたレコードの様々なビューは、したがって、検索者からの要求に応じて表現される可能性がある。ビューレコードは、またＨＴＭＬ互換環境で効果的な表現ためにＨＴＭＬでフォーマット化される。

［本発明の好ましい実施形態のユーザインタフェース］
本発明の好ましい実施形態のユーザインタフェースは図３〜６に示される。

図３は、本発明のステップ２０１のユーザインタフェースを示す。この場合、上記検索者、例えば工場オペレータは、例えば組み立て装置のような上記インターフェースから特定の装置を選択する。

特定の装置が選択された後、図４に示す本発明のステップ２０２によれば、上記インターフェースは検索者に選択された装置と関連するパラメータを選択することを促す。例えば、クエリ形式は、例えばMODE_BLK.ACTUAL、MODE_BLK.PERMITTED及びMODE_BLK.TARGETのようなパラメータの１組に基づくクエリである可能性がある。この場合、検索者はパラメータMODE_BLK.TARGETを選択する。

ステップ２０２とステップ２０３において、クエリの性質とソースに基づいて、上記クエリはデータベース２０５で実行される。ステップ２０７において、ユーザにより連続して更新されるデータベース２０６のレコードは、パラメータのリアルタイム値を具備する。検索するための適切なインデックスファイル１は、次いでそれぞれテキストインデックスファイル、メタデータインデックスファイル、プロパティインデックスファイルあるいは一般のクエリインデックスファイルのそれぞれである可能性がある。

一旦検索するのに適切なインデックスファイルが特定されるならば、ステップ２０５で、選択された装置のパラメータのリアルタイム値は検索者に表示される。検索者は、同様に選択された装置のパラメータの履歴の値を見るためのオプションを有する可能性がある。さらに、検索者は、スクリーン上に表示されたパラメータ値を活性化させることにより１つのパラメータから選択された装置の別のパラメータへナビゲートする可能性もある。この場合、図５で示すように、選択された装置のパラメータMODE_BLK.TARGETの履歴の値は、検索者に表示される。図示のように、最初の登録とメンテナンスチェックの間の選択された装置のパラメータMODE_BLK.TARGETの値は、それぞれ3.1と5.5である。この場合、最初の登録は検索がシステム上の装置を登録するときの初めの段階を示し、メンテナンスチェックはメンテナンスチェックを実行するかどうか検索するときの段階を示す。

ステップ２０５において、クエリが満足されたかどうか、あるいは、クエリが部分的に満足されるだけだったかどうかが、決定される。もし部分的に満足されるだけだったクエリが存在するならば、課程がステップ２０１に進行し、そこで検索者は別の装置あるいは別のパラメータを選択する。クエリが１以上の装置のために必要である環境において、上記検索者は複数の装置と彼らのそれぞれのパラメータを検索するオプションを有する可能性があり、そのため全体的な検索結果は１つのスクリーンで同時にビューされる可能性がある。もしクエリが完全に満足されるならば、上記検索者は、選択的なアクション、オブジェクト、及び／あるいは特定の用語を表示する装置のパラメータウインドウを見る選択をする可能性がある。この場合、図６で示すように、検索者がパラメータMODE_BLK.TARGETを選択するとき、装置パラメータは表示される。図示のように、装置パラメータウインドウは、例えば最後の更新されたユーザ、理由、パラメータの目標値、パラメータの実際の値、パラメータの許容された値、パラメータの通常の値、等のようなパラメータMODE_BLK.TARGETのより大きな詳細を表示する。

従って、上記レコードは、例えばＨＴＭＬあるいはＸＭＬのような広く認められたデータフォーマットに保存されて、したがって、ＨＴＭＬあるいはＸＭＬ互換の環境で効率的に表現される。つまり、上記レコードは、それと関連するデータをフォーマット化する完全な表示を有する、そのため、一旦検索クライテリアを満足するレコードが特定され、位置されるならば、それらは、ダイナミックなページの創造、フォーマット化等の必要なしで検索され、表示装置で検索者に表現される可能性がある。

上記レコードはそれぞれ、それと関連するマスタードキュメントを有し、様々なスタイル、サイズ、フォーマット、及び量のそれぞれのレコードと関連する様々な表示ドキュメントのオプションを有する可能性がある。選択されたレコードの様々なビューは、それゆえ検索者からのリクエストに応じて提示される可能性がある。ビューレコードは、ＨＴＭＬ互換の環境で、効果的な表現のためにＨＴＭＬでもフォーマット化される。

本発明の典型的な実施形態が示され、記載されたが、本発明の精神から逸脱することなく、多数の変化、修正、あるいはここに記載された本発明の代替がなされる可能性がありことは当業者にとって明らかである。それゆえそのような全ての変化、修正、及び変更は、本発明の範囲内であるように見られなければならない。

データベースのインデックスファイルの１実施形態の組織を示す図である。 本発明の概念によるクエリに基づくレコードに特定しアクセスするのに使用される典型的な段階を表すフローチャートを示す。 本発明の一実施形態のユーザインタフェースを示す図である。 本発明の一実施形態のユーザインタフェースを示す図である。 本発明の一実施形態のユーザインタフェースを示す図である。 本発明の一実施形態のユーザインタフェースを示す図である。

Claims (10)

1. データベースを検索する方法であって、
   上記データベースはコンピュータが読み込み可能な装置に記憶された複数のレコードを備え、上記複数のレコードのそれぞれは１以上の複数のドキュメントを備え、インデックスファイルは複数の装置識別子を備え、上記装置識別子のそれぞれは複数のパラメータ識別子を備え、上記パラメータ識別子のそれぞれはリアルタイム値を有し、上記方法は、
   上記装置識別子に関連される装置を選択する段階と、
   上記選択された装置に関連されるパラメータ識別子を選択する段階と、
   上記データベースの検索クライテリアを備える検索クエリを受信する段階と、
   上記検索クエリに応答する上記データベースを検索する段階と、
   上記検索クライテリアを満足するレコードを表示する段階とを備えるデータベースを検索する方法。
2. 上記レコードは、そのレコードと関連するデータをフォーマット化する表示であって、対応する完全な表示を有し、上記データをフォーマット化する表示であって、対応する完全な表示により特定されるフォーマットの表示装置上に上記レコードを表示する段階を更に備えることを特徴とする請求項１に記載の方法。
3. 上記レコードは、マスタードキュメント及びビュードキュメントを備える第１評価レコードを備えることを特徴とする請求項１あるいは２に記載の方法。
4. 上記インデックスファイルは、メタデータファイルであることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 上記表示は、１以上の装置に関連するデータをフォーマット化する表示であって、対応する完全な表示を有する上記レコードを示すことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 検索者は、表示されたパラメータ値を活性化することにより、１つのパラメータ識別子から選択された装置の別のパラメータ識別子にナビゲートする可能性があることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. データベースを備えるシステムであって、上記データベースは、
   コンピュータが読み込み可能な装置に記憶され、それぞれが１以上の複数のドキュメントを備える複数のレコードと、
   複数の装置識別子を備えるインデックスファイルと、
   それぞれ、複数のパラメータ識別子を備える装置識別子と、
   それぞれ、リアルタイム値を有するパラメータ識別子とを備えることを特徴とするシステム。
8. 上記レコードは、そのレコードと関連するデータをフォーマット化する表示であって、対応する完全な表示を有することを特徴とする請求項７に記載の方法。
9. 上記レコードは、マスタードキュメント及びビュードキュメントを備える第１評価レコードを備えることを特徴とする請求項７あるいは８に記載のシステム。
10. 上記インデックスファイルは、メタデータファイルであることを特徴とする請求項７乃至９のいずれか１項に記載のシステム。