JP6801195B2 - 検索処理方法、検索処理装置及び検索処理プログラム - Google Patents

Description

本発明は、データの検索技術に関する。

マテリアライズドビューは、ＤＢＭＳ（DataBase Management System）における通常のビューとは異なり実体を有する永続的なビューであるため、参照が終了しても消滅しない。従って、特定のビューを頻繁に参照するような場合、マテリアライズドビューを利用することで、参照の度に実行していた演算を省略して処理を高速化することができる。

特開２０１３−１１７８７３号公報

但し、元のテーブルとマテリアライズドビューとが必ずしもリアルタイムで同期されるわけではないので、最新ではないデータが参照される可能性がある。また、データを更新する場合には、元のテーブルの更新とマテリアライズドビューの再生成との両方が行われるため処理が遅延することがある。

また、或る対象に関する複数の属性値を格納した複数のテーブルからマテリアライズドビューを生成する場合、マテリアライズドビューのレコード数が膨大になり、現実的にはマテリアライズドビューを生成することができないことがある。たとえマテリアライズドビューを生成することができたとしても、レコード数が膨大である場合には実時間で処理を行うことはできない。

本発明の目的は、１つの側面では、検索の高速化と検索に使用するデータの少量化とを両立するための技術を提供することである。

本発明に係る検索処理方法は、検索条件を受け付け、第１属性の一意な属性値と、第１属性以外の１または複数の属性の属性値を含む属性値群とを関連付ける第１情報に基づき、第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が検索条件を満たすかを判定し、少なくとも、検索条件を満たすと判定された属性値群に関連付けられた第１属性の一意な属性値を出力する処理を含む。

１つの側面では、検索の高速化と検索に使用するデータの少量化とを両立できるようになる。

図１は、本実施の形態のシステム概要を示す図である。 図２は、本実施の形態において検索対象となるデータの一例を示す図である。 図３は、検索対象となるデータの管理の方法について説明するための図である。 図４は、管理データ格納部に格納されるデータの一例を示す図である。 図５は、管理データによって表されるツリーの構造を示す図である。 図６は、データ格納部に格納されるデータの一例を示す図である。 図７は、追加要求を受信した場合に実行する処理の処理フローを示す図である。 図８は、追加要求、更新要求及び削除要求に含まれる命令データの一例を示す図である。 図９は、検索要求を受信した場合に実行する処理の処理フローを示す図である。 図１０は、検索要求の一例を示す図である。 図１１は、判定結果を管理するためのデータの一例を示す図である。 図１２は、検索の際に結合演算を実行する方法について説明するための図である。 図１３は、検索の際に結合演算を実行する方法について説明するための図である。 図１４は、本実施の形態の検索方法について説明するための図である。 図１５は、マテリアライズドビューを利用して検索を実行する方法について説明するための図である。 図１６は、マテリアライズドビューを利用して検索を実行する方法について説明するための図である。 図１７は、マテリアライズドビューを利用して検索を実行する方法について説明するための図である。 図１８は、本実施の形態の方法によって生成されるツリー構造の一例を示す図である。 図１９は、マテリアライズドビューを利用して検索を実行する方法と、本実施の形態の方法との比較するための図である。 図２０は、コンピュータの機能ブロック図である。

図１に、本実施の形態のシステムの概要を示す。本実施の形態の主要な処理を実行する情報処理装置１は、例えばＬＡＮ（Local Area Network）であるネットワーク５に接続される。ネットワーク５には、ユーザによって操作されるユーザ端末３が接続される。

情報処理装置１は、第１受付部１０１と、取得部１０２と、アセット更新部１０３と、第１応答部１０４と、第２受付部１０５と、解析部１０６と、アセット検索部１０７と、第２応答部１０８と、管理データ格納部１０９と、データ格納部１１０とを含む。

第１受付部１０１は、レコードを追加することについての追加要求、レコードを更新することについての更新要求およびレコードを削除することについての削除要求をユーザ端末３から受信し、取得部１０２に出力する。取得部１０２は、ユーザ端末３から受信した要求から、キー情報を含む命令データを取得し、アセット更新部１０３に出力する。アセット更新部１０３は、取得部１０２から受け取った命令データに従い、管理データ格納部１０９に格納されたデータおよびデータ格納部１１０に格納されたデータの少なくともいずれかを更新する。アセット更新部１０３は、更新が完了したことを第１応答部１０４に通知する。第１応答部１０４は、更新が完了したことを示すデータをユーザ端末３に送信する。

第２受付部１０５は、レコードを検索することについての検索要求をユーザ端末３から受信し、解析部１０６に出力する。解析部１０６は、ユーザ端末３から受信した検索要求を解析し、検索要求に含まれる検索条件および論理演算子等をアセット検索部１０７に出力する。アセット検索部１０７は、解析部１０６から受け取ったデータと管理データ格納部１０９に格納されたデータとに基づき、データ格納部１１０からレコードセットを取得する。アセット検索部１０７は、取得したレコードセットを第２応答部１０８に出力する。第２応答部１０８は、受け取ったレコードセットを含むデータをユーザ端末３に送信する。

本実施の形態においては、複数の属性の属性値によって表される対象についてのデータを検索対象とする。本実施の形態において検索対象となるデータは、例えば、図２に示すような従業員情報である。従業員情報は、一意な（すなわち、重複がない）従業員コードに関連付けられた、勤務地等の情報を含む基本的な情報（以下、基本データと呼ぶ）、旅費に関する情報（以下、旅費データと呼ぶ）、教育に関する情報（以下、教育データと呼ぶ）および給与に関する情報（以下、給与データと呼ぶ）などを含む。このような情報はその種類によって更新されるタイミングが異なり、また、レコードの数も異なる。例えば、給与データは月に１回レコードが追加されるが、教育データ（例えば英語のスコア等）は不定期にレコードが更新又は追加される。また、例えば、旅費データおよび給与データのレコード数は勤務の期間が長くなるに従って増加するが、生年月日に関するレコードの数は１であり不変である。

図３を用いて、検索対象となるデータの管理方法について説明する。図３において、ハッチが付された矩形はレコードを表し、楕円の図形はレコードのレコードＩＤ（IDentifier）を表す。基本データのレコード、旅費データのレコードおよび教育データのレコードは、データ格納部１１０に受信順に格納され、各レコードにはレコードＩＤが割り振られる。管理データ格納部１０９において、基本データのレコードのレコードＩＤ、旅費データのレコードのレコードＩＤおよび教育データのレコードのレコードＩＤは、従業員コードによって束ねられる。

図４に、管理データ格納部１０９に格納される管理データの一例を示す。図４（ａ）は、管理データによって表されるツリーの根がポイントする従業員の従業員コードを示す図である。図４（ｂ）、図４（ｃ）および図４（ｄ）は、各従業員コードがポイントするレコードのレコードＩＤを示す図である。よって、管理データによって表されるツリーの構造は、図５に示された構造である。図５に示すように、根には従業員コードが接続され、従業員コードにはその従業員コードが付与された従業員のレコードのレコードＩＤが接続される。以下では、１つの従業員コードと１又は複数のレコードＩＤとによって形成されるツリーのことをノードと呼ぶ。よって、図５の例では３つのノードが存在する。

図６に、データ格納部１１０に格納されるデータの一例を示す。図６の例では、レコードＩＤと、レコードとが格納される。レコードは受信順に格納される。

次に、図７乃至図１１を用いて、情報処理装置１の動作を説明する。はじめに、図７及び図８を用いて、情報処理装置１が追加要求を受信した場合に実行する処理について説明する。

まず、情報処理装置１の第１受付部１０１は、ユーザ端末３から追加要求を受信し（図７：ステップＳ１）、追加要求を取得部１０２に出力する。そして、取得部１０２は、追加要求から命令データを取得し（ステップＳ３）、取得した命令データをアセット更新部１０３に出力する。図８（ａ）に、追加要求に含まれる命令データの一例を示す。この命令データによってデータ格納部１１０に「new_data」が追加される。

なお、図８（ｂ）は更新要求に含まれる命令データの一例を示す図であり、この命令データによって「recordID」が付与されたレコードが「update_data」に更新される。図８（ｃ）は削除要求に含まれる命令データの一例を示す図であり、この命令データによって「recordID」が割り振られたレコードが削除される。

アセット更新部１０３は、取得した命令データに含まれるキー情報（本実施の形態においては従業員コード。図８においては「node_tree」）が管理データ格納部１０９に格納されているか判定する（ステップＳ５）。

命令データに含まれるキー情報が管理データ格納部１０９に有る場合（ステップＳ５：Ｙｅｓルート）、ステップＳ９の処理に移行する。一方、命令データに含まれるキー情報が管理データ格納部１０９に格納されていない場合（ステップＳ５：Ｎｏルート）、アセット更新部１０３は、命令データに含まれるキー情報を管理データ格納部１０９に格納する（ステップＳ７）。

アセット更新部１０３は、新規に割り振られたレコードＩＤ（具体的には、最後に割り振られたレコードＩＤの次レコードＩＤ）を、ステップＳ７において格納されたキー情報がポイントするレコードのＩＤとして管理データ格納部１０９に格納する（ステップＳ９）。

アセット更新部１０３は、命令データに含まれるレコード（図８においては「new_data」）を、新規に割り振られたレコードＩＤに関連付けてデータ格納部１１０に格納する（ステップＳ１１）。そして処理は終了する。

そして、アセット更新部１０３は、更新が完了したことを第１応答部１０４に通知する。第１応答部１０４は、更新が完了したことを示すデータを、要求元の端末であるユーザ端末３に送信する。

以上のような処理を実行すれば、マテリアライズドビューのような２次情報と比較してサイズが小さいデータを生成できるようになる。また、本実施の形態のような管理データ格納部１０９及びデータ格納部１１０を利用すれば、実際に検索対象となるデータをリアルタイムで更新できるようになり、また、更新処理を原因とする処理遅延が生じない。

次に、図９乃至図１１を用いて、情報処理装置１が検索要求を受信した場合に実行する処理について説明する。

まず、情報処理装置１の第２受付部１０５は、ユーザ端末３から検索要求を受信し（図９：ステップＳ２１）、受信した検索要求を解析部１０６に出力する。そして、解析部１０６は、第２受付部１０５から受け取った検索要求に含まれる検索式を解析し（ステップＳ２３）、検索式から検索条件および論理演算子等を取得する。解析部１０６は、取得した検索条件および論理演算子等をアセット検索部１０７に出力する。

図１０に、検索要求の一例を示す。図１０（ａ）に示された検索要求は、勤務地が神戸であるレコードのレコードＩＤ及び出張先が新横浜であるレコードのレコードＩＤに関連付けられたノードを検索し、該当するノードのノードセット（キー情報および各レコード）を返信するための検索要求である。図１０（ｂ）に示された検索要求は、勤務地が神戸であるレコードのレコードＩＤ及び出張先が新横浜であるレコードのレコードＩＤに関連付けられたノードを検索し、該当するノードの「／基本データ／所属」に相当するレコード及びそのレコードＩＤを返信するための検索要求である。

なお、図１０（ｃ）は、本実施の形態の方法を使用しない場合における一般的な検索要求の一例を示す図であり、この検索要求によりレコード単位で検索が行われ、該当するレコードのレコードＩＤが返信される。すなわち、本実施の形態のようにノード単位で検索が行われるわけではない。

アセット検索部１０７は、管理データ格納部１０９において登録されているノードのうち未処理のノードを１つ特定する（ステップＳ２５）。

アセット検索部１０７は、管理データ格納部１０９から、ステップＳ２５において特定したノードの従業員コードに関連付けられたレコードＩＤのうち未処理のレコードＩＤを１つ特定する（ステップＳ２７）。

アセット検索部１０７は、ステップＳ２７において特定したレコードＩＤに関連付けられたレコードをデータ格納部１１０から特定し、特定したレコードが各検索条件を満たすか判定する（ステップＳ２９）。例えば、特定したレコードが図６に示したレコードＩＤ「ｒ０００４」のレコードであり、且つ、検索式に含まれる検索条件が「／基本データ／勤務地＝”神戸”」及び「／旅費データ／出張先＝”新横浜”」である場合、検索条件「／旅費データ／出張先＝”新横浜”」が満たされると判定される。判定結果は、メモリに格納された、図１１に示すようなデータによって管理される。図１１において、満たされると判定された検索条件については「Ｔ」が格納される。満たされないと判定された検索条件については何も格納されない。本データは１つのノードについての処理が開始した時点で生成され、そのノードについての処理が終了した時点で削除される。

アセット検索部１０７は、ステップＳ２５において特定したノードの従業員コードに関連付けられたレコードＩＤのうち未処理のレコードＩＤが有るか判定する（ステップＳ３１）。未処理のレコードＩＤが有る場合（ステップＳ３１：Ｙｅｓルート）、ステップＳ２７の処理に戻る。

一方、未処理のレコードＩＤが無い場合（ステップＳ３１：Ｎｏルート）、アセット検索部１０７は、各検索条件の判定結果に基づき、検索式の論理演算の評価を実行する（ステップＳ３３）。例えば、或るノードについて図１１に示した判定結果が得られ、且つ、検索式が図１０（ａ）に示した検索式（／基本データ／勤務地＝”神戸” ａｎｄ ／旅費データ／出張先＝”新横浜”）である場合、２つ目の検索条件は満たされるが１つ目の検索条件が満たされないので、論理演算の評価は「偽」である。

アセット検索部１０７は、ステップＳ３３の評価が「真」であるか判定する（ステップＳ３５）。ステップＳ３３の評価が「真」ではない場合（ステップＳ３５：Ｎｏルート）、ステップＳ３９の処理に移行する。

一方、ステップＳ３３の評価が「真」である場合（ステップＳ３５：Ｙｅｓルート）、アセット検索部１０７は、ステップＳ２５において特定されたノードのレコードセット（すなわち、このノードについての全レコードおよび従業員コード）を第２応答部１０８に出力する。そして、第２応答部１０８は、アセット検索部１０７から受け取ったレコードセットを、要求元の端末であるユーザ端末３に送信する（ステップＳ３７）。なお、ステップＳ３７においてはレコードセットを送信しているが、検索式の内容によっては、レコードセットの一部だけ送信する場合もある。

アセット検索部１０７は、未処理のノードが有るか判定する（ステップＳ３９）。未処理のノードが有る場合（ステップＳ３９：Ｙｅｓルート）、ステップＳ２５の処理に戻る。一方、未処理のノードが無い場合（ステップＳ３９：Ｎｏルート）、処理は終了する。

以下では、本実施の形態の検索方法と他の検索方法とを具体例を用いて比較する。

図１２及び図１３を用いて、検索の際に結合演算を実行する方法について説明する。図１２においては、従業員と勤務地との関係は１対１であるが、従業員と出張先との関係は１対ｋ（ｋは自然数）である。基本データのテーブルからは「基本データ．勤務地 ＝ ”沼津”」を満たすレコード及び「基本データ．勤務地 ＝ ”神戸”」を満たすレコードが抽出される。一方、旅費データのテーブルからは「旅費データ．出張先 ＝ ”蒲田”」を満たすレコード及び「旅費データ．出張先 ＝ ”新横浜”」を満たすレコードが抽出される。ここでは、例えば図１３に示すようなＳＱＬ（Structured Query Language）に従って各テーブルから検索条件を満たすレコードが抽出される。そして、レコード間の関係演算（ここでは、結合演算）を実行することで結果が導出される。ここでは、従業員「Ｚ」が最終的な結果である。

検索の際に結合演算を実行する方法においては、各テーブルから抽出される中間結果のレコード数が膨大になることがあり、それが原因となり関係演算の対象となるレコードの数が膨大になることがある。また、演算時の実行計画が予め作成されていなければならない。

一方、本実施の形態においては、図１４に示すように、ノード毎に判定が行われる。図１４においては、まず従業員「Ｘ」のノードについて判定が行われ、次に従業員「Ｙ」のノードについて判定が行われ、最後に従業員「Ｚ」のノードについて判定が行われる。そして、最終的な結果は従業員「Ｚ」である。

このように、本実施の形態においては、結合演算を実行する際に生じるような膨大な量の中間結果を生じさせることがなく、異種のレコードに対して仮想的に結合演算を行い、１つのデータであるとみなして判定することができる。これにより、高速な検索を実行することが可能である。

図１５乃至図１７を用いて、マテリアライズドビューを利用して検索を実行する方法について説明する。例えば図１５に示すような、企業で働く従業員の情報が蓄積された複数のテーブルがあるとする。図１５（ａ）には従業員コードに関連付けて名前が格納される従業員マスタが示されており、図１５（ｂ）には従業員コードに関連付けて勤務地と期間とが格納される基本データテーブルが示されており、図１５（ｃ）には従業員コードに関連付けて英語のスコアが格納される教育データテーブルが示されている。

ここで、Ｐは従業員数を表し、ｍは１名あたりの基本データの属性値数の平均を表し、ｎは１名あたりの教育データの属性の属性値数の平均を表す。

図１５に示した３つのテーブルを、例えば図１６（ａ）に示すようなコードによって処理すれば、マテリアライズドビューを生成することができる。図１７に、生成されるマテリアライズドビューの一例を示す。図１７の例においては、名前と、勤務地と、英語スコアとがマテリアライズドビューに含まれる。例えば図１６（ｂ）に示すようなコードによって、マテリアライズドビューに対する問い合わせが行われる。図１６（ｂ）のコードによれば、ドイツでの勤務経験を有し且つ英語スコアが９００以上である従業員が探索される。

このとき、マテリアライズドビューのレコード数はＰ＊ｍ＊ｎで表される。そして、名前のデータサイズがＳαであるとし、勤務地のデータサイズがＳβであるとし、英語スコアのデータサイズがＳγであるとすると、マテリアライズドビューのデータサイズは（Ｐ＊ｍ＊ｎ）＊（Ｓα＋Ｓβ＋Ｓγ）で表される。

一方、図１５に示した３つのテーブルに対して本実施の形態の方法を適用する場合、従業員コードをキー情報とすると、図１８に示すようなツリー構造が生成される。すなわち、３つのテーブルの間の結合関係はノードによって表され、属性が異なる複数の属性値が同じノードにて管理される。

このとき、ノードの数はＰで表され、各ノードの配下にある属性値の数は（１＋ｍ＋ｎ）で表される。そして、各ノードの従業員コードのデータサイズがＳδであるとし、ノードの配下にある属性値のデータサイズがＳεであるとすると、本実施の形態において検索の対象となるデータのサイズはＰ＊Ｓδ＋Ｐ＊（ｍ＋ｎ）＊Ｓεで表される。

図１９は、マテリアライズドビューを利用して検索を実行する方法と、本実施の形態の方法との比較するための図である。例えば従業員数が２００００であり、ｍ＝１０且つｎ＝５０である場合、マテリアライズドビューを利用するとＰ＊ｍ＊ｎ＝２００００＊１０＊５０＝１０００００００のレコードが検索の対象になる。一方、本実施の形態の方法であれば、Ｐ＊（１＋ｍ＋ｎ）＝２００００＊（１＋１０＋５０）＝１２２００００であるので、マテリアライズドビューを利用する場合と比較すると約１／８である。このように、マテリアライズドビューを利用する場合、レコード数およびデータサイズが幾何級数的に増加する。従って、従業員の数が多くなると現実的にはマテリアライズドビューを生成することができない。また、たとえマテリアライズドビューを生成することができたとしても実時間で処理を行うことはできない。一方、本実施の形態の方法であれば、マテリアライズドビューを利用する場合と比較すると、レコード及びデータサイズが算術級数的に増加するので、管理される属性の数及び属性値の数が増加してもデータサイズが爆発的に増加することがない。

また、マテリアライズドビューを利用して検索を実行する場合、元のテーブルの更新とマテリアライズドビューの再生成との両方を行うことによって処理遅延が生じることがあるが、本実施の形態の方法であればそのような問題は生じない。本実施の形態の方法であれば、全体を再生成せずに部分的に更新すればよいので、リアルタイムにデータを更新することができるようになる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した情報処理装置１の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明した各テーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

また、従業員コードのような情報以外の情報をキー情報として利用してもよい。例えば、或る病院の医療コンテンツが診察データテーブル、薬剤データテーブルおよび会計データテーブルで管理されている場合、診察データテーブルの患者ＩＤおよび会計データテーブルの顧客ＩＤがこれらのテーブルを結び付ける結合キーであるので、その値を利用してもよい。

また、例えば、サーバルームに設置された数百台のサーバから送られてくるセンサデータのファイル名は「サーバ名＋日時」で表されていることがある。そこで、センサデータを検索対象とする場合には、センタデータのファイル名からサーバ名を取得し、キー情報として利用してもよい。

また、例えば、買い物かごに装着されたセンサタグによって、客が買い物かごを手に取ってから買い物を完了するまでの行動のデータが取得されることがある。この場合には、買い物という行為をトランザクションとみなし、買い物かごではなく買い物という行為自体にキー情報を割り振ってもよい。

なお、上で述べた情報処理装置１は、コンピュータ装置であって、図２０に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

なお、管理データ格納部１０９はメモリ２５０１上に設けられ、データ格納部１１０はＨＤＤ２５０５上に設けられてもよい。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係る検索処理方法は、（Ａ）検索条件を受け付け、（Ｂ）第１属性の一意な属性値と、第１属性以外の１または複数の属性の属性値を含む属性値群とを関連付ける第１情報に基づき、第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が検索条件を満たすかを判定し、（Ｃ）少なくとも、検索条件を満たすと判定された属性値群に関連付けられた第１属性の一意な属性値を出力する処理を含む。

これにより、結合演算をすることがなく、また、マテリアライズドビューのようなデータを使用することもないので、検索の高速化と検索に使用するデータの少量化とを両立できるようになる。

また、上で述べた第１情報は、第１属性の一意な属性値と、第１属性以外の１または複数の属性の属性値の識別子とを関連付ける第２情報と、第１属性以外の１または複数の属性の属性値の識別子と当該属性値とを関連付ける第３情報とを含んでもよい。そして、属性値群が検索条件を満たすかを判定する処理において、（ｂ１）第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた第１属性以外の１または複数の属性の属性値の識別子を第２情報に基づき特定し、特定された識別子に関連付けられた属性値を第３情報に基づき特定し、特定された当該属性値が検索条件を満たすかを判定してもよい。このような第２情報および第３情報であれば、マテリアライズドビューにおいて使用されるデータよりもサイズは小さくなる。

また、本検索処理方法は、（Ｄ）第１属性の第１属性値と第１属性以外の属性の第２属性値とを受信し、（Ｅ）受信した第１属性値が第２情報に含まれるかを判定し、（Ｆ）第１属性値が第２情報に含まれる場合、第２情報に含まれる第１属性値に、第２属性値の識別子を関連付け、（Ｇ）第３情報に、第２属性値の識別子と第２属性値との関連付けを追加する処理をさらに含んでもよい。これにより、実際に検索対象となる情報をリアルタイムで更新できるようになる。

また、本検索処理方法は、（Ｈ）第１属性値が第２情報に含まれない場合、第２情報に、第１属性値と第２属性値の識別子との関連付けを追加し、（Ｉ）第３情報に、第２属性値の識別子と第２属性値との関連付けを追加する処理をさらに含んでもよい。これにより、実際に検索対象となる情報をリアルタイムで更新できるようになる。

また、上で述べた検索条件は、属性と当該属性の属性値との組み合わせを１または複数含んでもよい。

なお、上記方法による処理をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
コンピュータに、
検索条件を受け付け、
第１属性の一意な属性値と、前記第１属性以外の１または複数の属性の属性値を含む属性値群とを関連付ける第１情報に基づき、前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が前記検索条件を満たすかを判定し、
少なくとも、前記検索条件を満たすと判定された属性値群に関連付けられた第１属性の一意な属性値を出力する、
処理を実行させる検索処理プログラム。

（付記２）
前記第１情報は、前記第１属性の一意な属性値と、前記第１属性以外の１または複数の属性の属性値の識別子とを関連付ける第２情報と、前記第１属性以外の１または複数の属性の属性値の識別子と当該属性値とを関連付ける第３情報とを含み、
前記属性値群が前記検索条件を満たすかを判定する処理において、
前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた前記第１属性以外の１または複数の属性の属性値の識別子を前記第２情報に基づき特定し、特定された前記識別子に関連付けられた属性値を前記第３情報に基づき特定し、特定された当該属性値が前記検索条件を満たすかを判定する、
付記１記載の検索処理プログラム。

（付記３）
前記コンピュータに、
前記第１属性の第１属性値と前記第１属性以外の属性の第２属性値とを受信し、
受信した前記第１属性値が前記第２情報に含まれるかを判定し、
前記第１属性値が前記第２情報に含まれる場合、前記第２情報に含まれる前記第１属性値に、前記第２属性値の識別子を関連付け、
前記第３情報に、前記第２属性値の識別子と前記第２属性値との関連付けを追加する、
処理をさらに実行させる付記２記載の検索処理プログラム。

（付記４）
前記コンピュータに、
前記第１属性値が前記第２情報に含まれない場合、前記第２情報に、前記第１属性値と前記第２属性値の識別子との関連付けを追加し、
前記第３情報に、前記第２属性値の識別子と前記第２属性値との関連付けを追加する、
処理をさらに実行させる付記３記載の検索処理プログラム。

（付記５）
前記検索条件は、属性と当該属性の属性値との組み合わせを１または複数含む、
付記１乃至４のいずれか１つ記載の検索処理プログラム。

（付記６）
コンピュータが、
検索条件を受け付け、
第１属性の一意な属性値と、前記第１属性以外の１または複数の属性の属性値を含む属性値群とを関連付ける第１情報に基づき、前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が前記検索条件を満たすかを判定し、
少なくとも、前記検索条件を満たすと判定された属性値群に関連付けられた第１属性の一意な属性値を出力する、
処理を実行する検索処理方法。

（付記７）
検索条件を受け付ける受付部と、
第１属性の一意な属性値と、前記第１属性以外の１または複数の属性の属性値を含む属性値群とを関連付ける第１情報に基づき、前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が前記検索条件を満たすかを判定する判定部と、
少なくとも、前記検索条件を満たすと前記判定部により判定された属性値群に関連付けられた第１属性の一意な属性値を出力する出力部と、
を有する検索処理装置。

１ 情報処理装置 １０１ 第１受付部
１０２ 取得部 １０３ アセット更新部
１０４ 第１応答部 １０５ 第２受付部
１０６ 解析部 １０７ アセット検索部
１０８ 第２応答部 １０９ 管理データ格納部
１１０ データ格納部 ３ ユーザ端末
５ ネットワーク

Claims (6)

1. コンピュータに、
   検索条件を受け付け、
   第１属性の一意な属性値から、前記第１属性以外の１または複数の属性の属性値を含む属性値群を関連付ける第１情報に基づき、前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が前記検索条件を満たすかを判定し、
   少なくとも、前記検索条件を満たすと判定された属性値群に対する第１属性の一意な属性値を出力する、
   処理を実行させ、
   前記第１情報は、前記第１属性の一意な属性値から、前記第１属性以外の１または複数の属性の属性値の識別子を関連付ける第２情報と、前記第１属性以外の１または複数の属性の属性値の識別子と当該属性値とを関連付ける第３情報とを含み、
   前記属性値群が前記検索条件を満たすかを判定する処理において、
   前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた前記第１属性以外の１または複数の属性の属性値の識別子を前記第２情報に基づき特定し、特定された前記識別子に関連付けられた属性値を前記第３情報に基づき特定し、特定された当該属性値が前記検索条件を満たすかを判定する
   検索処理プログラム。
2. 前記コンピュータに、
   前記第１属性の第１属性値と前記第１属性以外の属性の第２属性値とを受信し、
   受信した前記第１属性値が前記第２情報に含まれるかを判定し、
   前記第１属性値が前記第２情報に含まれる場合、前記第２情報に含まれる前記第１属性値に、前記第２属性値の識別子を関連付け、
   前記第３情報に、前記第２属性値の識別子と前記第２属性値との関連付けを追加する、
   処理をさらに実行させる請求項１記載の検索処理プログラム。
3. 前記コンピュータに、
   前記第１属性値が前記第２情報に含まれない場合、前記第２情報に、前記第１属性値と前記第２属性値の識別子との関連付けを追加し、
   前記第３情報に、前記第２属性値の識別子と前記第２属性値との関連付けを追加する、
   処理をさらに実行させる請求項２記載の検索処理プログラム。
4. 前記検索条件は、属性と当該属性の属性値との組み合わせを１または複数含む、
   請求項１乃至３のいずれか１つ記載の検索処理プログラム。
5. コンピュータが、
   検索条件を受け付け、
   第１属性の一意な属性値から、前記第１属性以外の１または複数の属性の属性値を含む属性値群を関連付ける第１情報に基づき、前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が前記検索条件を満たすかを判定し、
   少なくとも、前記検索条件を満たすと判定された属性値群に対する第１属性の一意な属性値を出力する
   処理を実行し、
   前記第１情報は、前記第１属性の一意な属性値から、前記第１属性以外の１または複数の属性の属性値の識別子を関連付ける第２情報と、前記第１属性以外の１または複数の属性の属性値の識別子と当該属性値とを関連付ける第３情報とを含み、
   前記属性値群が前記検索条件を満たすかを判定する処理において、
   前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた前記第１属性以外の１または複数の属性の属性値の識別子を前記第２情報に基づき特定し、特定された前記識別子に関連付けられた属性値を前記第３情報に基づき特定し、特定された当該属性値が前記検索条件を満たすかを判定する
   検索処理方法。
6. 検索条件を受け付ける受付部と、
   第１属性の一意な属性値から、前記第１属性以外の１または複数の属性の属性値を含む属性値群を関連付ける第１情報に基づき、前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた属性値群が前記検索条件を満たすかを判定する判定部と、
   少なくとも、前記検索条件を満たすと前記判定部により判定された属性値群に対する第１属性の一意な属性値を出力する出力部と、
   を有し、
   前記第１情報は、前記第１属性の一意な属性値から、前記第１属性以外の１または複数の属性の属性値の識別子を関連付ける第２情報と、前記第１属性以外の１または複数の属性の属性値の識別子と当該属性値とを関連付ける第３情報とを含み、
   前記判定部が、
   前記第１属性の属性値ごとに、当該第１属性の属性値に関連付けられた前記第１属性以外の１または複数の属性の属性値の識別子を前記第２情報に基づき特定し、特定された前記識別子に関連付けられた属性値を前記第３情報に基づき特定し、特定された当該属性値が前記検索条件を満たすかを判定する
   検索処理装置。

Images