(57)【要約】【課題】  検索条件に対応するリソースの数が閾値以下に限定される索引語を含む場合に、網羅的な検索結果を高速に回答可能とし、索引の総情報量の増大を抑える。【解決手段】  プログラム４０２は、プログラム４０１がユーザ端末から登録要求メッセージを受け取った場合、逆リソース表への登録においては、まず、外部プログラム４０６に該リソースＩＤとリソース情報とを渡し、答えとして１つ以上の準候補キーのリストを受け取り、該準候補キーのリストに従って、リソースＩＤがその値となるよう逆リソース表へ登録する。このとき、リソースの数が閾値以下に限定されない索引語については、対応するリソースの情報を消去する。これにより、索引語に対応するリソースの数を、所定の閾値以下に抑え、索引の総情報量の増大を抑える。【選択図】    図１
2006092509.tif 000002
【特許請求の範囲】
【請求項１】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する逆リソース表と、
前記識別ＩＤと前記リソース情報と準候補キーを対応付けて記憶しており、前記識別ＩＤあるいは前記リソース情報を受信して対応する前記準候補キーを応答する準候補キー検索手段と、
ユーザからの要求メッセージを受け取る受取手段と、
前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、前記準候補キー検索手段に該リソースの準候補キーを問合せ、準候補キー群を得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録する登録手段と、
前記逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていた識別ＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、前記逆リソース表への再登録を行う再登録手段と、
前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除する削除手段と、
前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、前記削除手段によって一旦削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、
前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する検索手段と、
前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と
を具備することを特徴とするリソース検索装置。
【請求項２】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する逆リソース表と、
ユーザからの要求メッセージを受け取る受取手段と、
前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録する登録手段と、
前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成する条件作成手段と、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行う再帰的登録手段と、
前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除する削除手段と、
前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、前記削除手段によって一旦削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、
前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する検索手段と、
前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と、
を具備することを特徴とするリソース検索装置。
【請求項３】
前記リソース情報は、単に１つ以上のメタ情報の集合であるのではなく、メタ情報間の親子関係情報を含む木構造で構成されるものであり、
前記条件は、リソース情報に含まれるメタ情報の部分集合だけではなく、リソース情報を構成する木構造の部分木も含むことを特徴とする請求項２記載のリソース検索装置。
【請求項４】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する、新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表と、
ユーザからの要求メッセージを受け取る受取手段と、
前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記２つの逆リソース表に登録する登録手段と、
前記２つの逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成する条件作成手段と、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行う再帰的登録手段と、
前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記２つの逆リソース表とから該リソースに関する情報を削除する削除手段と、
前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記２つの逆リソース表内の該リソースに関する情報を、前記削除手段によっていったん削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、
前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する検索手段と、
前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と、
ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成する逆リソース表更新手段と、
を具備することを特徴とするリソース検索装置。
【請求項５】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、
１つ以上のリソースについて、１つ以上の前記メタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する逆リソース表と、
ユーザからの要求メッセージを受け取る受取手段と、
前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録する登録手段と、
前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成する条件作成手段と、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行う再帰的登録手段と、
前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除する削除手段と、
前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、前記削除手段によっていったん削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、
前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤが含まれる場合には、前記順リソース表から該当するリソースのリソース情報を検索し、前記識別ＩＤが含まれずに１つ以上の前記メタ情報が含まれる場合には、前記旧逆リソース表から、まず前記要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了し、それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行し、試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とする検索手段と、
前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と、
を具備することを特徴とするリソース検索装置。
【請求項６】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、前記識別ＩＤあるいは前記リソース情報に対応する準候補キーを得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録し、
前記逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていた識別ＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、前記逆リソース表への再登録を行い、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除し、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新し、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索し、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信することを特徴とするリソース検索方法。
【請求項７】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録し、
前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行い、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除し、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新し、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索し、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信することを特徴とするリソース検索方法。
【請求項８】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表に保持し、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記２つの逆リソース表に登録し、
前記２つの逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行い、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記２つの逆リソース表とから該リソースに関する情報を削除し、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記２つの逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新し、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索し、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信し、
ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成することを特徴とするリソース検索方法。
【請求項９】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、
１つ以上のリソースについて、１つ以上の前記メタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録し、
前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行い、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除し、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新し、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤが含まれる場合には、前記順リソース表から該当するリソースのリソース情報を検索し、
前記識別ＩＤが含まれずに１つ以上の前記メタ情報が含まれる場合には、前記旧逆リソース表から、まず前記要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了し、
それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行し、
前記試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とし、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信することを特徴とするリソース検索方法。
【請求項１０】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持するステップと、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、前記識別ＩＤあるいは前記リソース情報に対応する準候補キーを得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録するステップと、
前記逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていた識別ＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、前記逆リソース表への再登録を行うステップと、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除するステップと、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新するステップと、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索するステップと、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、
を実行させるためのリソース検索プログラム。
【請求項１１】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持するステップと、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録するステップと、
前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成するステップと、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行うステップと、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除するステップと、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新するステップと、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索するステップと、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、
を実行させるためのリソース検索プログラム。
【請求項１２】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、
１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表に保持するステップと、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記２つの逆リソース表に登録するステップと、
前記２つの逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成するステップと、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行うステップと、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記２つの逆リソース表とから該リソースに関する情報を削除するステップと、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記２つの逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新するステップと、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索するステップと、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、
ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成するステップと、
を実行させるためのリソース検索プログラム。
【請求項１３】
大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、
１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、
１つ以上のリソースについて、１つ以上の前記メタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持するステップと、
ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録するステップと、
前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成するステップと、
前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行うステップと、
ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除するステップと、
ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新するステップと、
ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤが含まれる場合には、前記順リソース表から該当するリソースのリソース情報を検索し、
前記識別ＩＤが含まれずに１つ以上の前記メタ情報が含まれる場合には、前記旧逆リソース表から、まず前記要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了するステップと、
それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行するステップと、
前記試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とするステップと、
前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、
を実行させるためのリソース検索プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザが所有している、あるいはメタ情報を参照できるなど何らかの利用権を有している、各々が固有の識別ＩＤを持つリソース（物品や情報コンテンツ）について、ユーザからの要求に応じて、目的のリソースの識別ＩＤやメタ情報を記録あるいは回答するリソース検索システムにおける、１つ以上のメタ情報で構成される検索キーから、当該検索キーに適合する（リソース情報内に検索キーを構成するメタ情報を全て含む）リソースの識別ＩＤや他のメタ惰報を検索するリソース検索装置、リソース検索方法およびリソース検索プログラムに関する。
【背景技術】
【０００２】
今後の情報流通ネットワークで主要なサービスとなり得るユビキタスサービスの１つに、無線タグを物や人に貼り付け、無線タグリーダを様々な場所に設置することで、物や人の場所や状態（例えば、在庫か否か）などを管理・把握・利用する無線タグサービスがある。既に、Ａｕｔｏ−ＩＤ構想のように、物流管理を主な適用領域とし、固定フォーマットのＩＤで物品／リソースの名前を表現し、このＩＤ単位で物品情報／リソース情報の記録・回答を担当するデータベースを決定することでスケール性を確保するシステムの商用化か始まっている（例えば、非特許文献１参照）。
【０００３】
しかし、ユビキタスサービスにおける情報検索では、目的のリソースを指定する名前として、固定フォーマットのＩＤを用いた場合、人が名前とリソースとの対応を把握するのが困難であるため、どのようなリソースであるかを表現する柔軟で自己説明的な名前を用いることが望ましい。この自己説明的な名前は、メタ情報の集合と考えることができる。ユビキタスサービスに好適な名前として、無線タグサービスでは、ある特定の物品情報を得たい場合、対象がどんな物品であるか、例えば、製造会社名、型番、所有者氏名などを用いることが考えられる。このような名前（１つ以上のメタ情報）を検索条件として、適合する物品のＩＤ、あるいは物品情報を格納したデータベースのアドレスを効率的に取得するリソース検索システムが求められる。
【０００４】
ＩＮＳ（Intentional Naming System）と称されるＭＩＴの研究結果（例えば、非特許文献２参照）は、柔軟で自己説明的な名前を用いる名前解決機構／ディレクトリサービスである。「ｎａｍｅ−ｓｐｅｃｉｆｉｅｒ」と称されるＩＮＳにおける名前は、互いに依存関係を持つ複数のａｖペアと称されるメタ情報（属性名と属性値の組み合わせ）によって構成され、依存関係は木構造で表される（Ａｕｔｏ−ＩＤシステムにおける物品情報も同様の木構造を持つ）。
【０００５】
ＩＮＳ／Ｔｗｉｎｅと称される同じくＭＩＴの研究結果（例えば、非特許文献３参照）は、ＩＮＳにおける名前を「ｓｔｒａｎｄ」と称される１つ以上のａｖペアの組み合わせに、依存関係を維持し、かつ木構造の根から枝分かれせずに分解し、「ｓｔｒａｎｄ」とリソースの識別ＩＤとの対応を記録した表を分散ハッシュテーブルを用いて複数のデータベースで分散管理するものである。「ｓｔｒａｎｄ」は、枝分かれの無い単純な構造であるため、個々の「ｓｔｒａｎｄ」に対応するリソースの数が膨大になる可能性がある。この場合、データベースの過負荷を避けるため、「ｓｔｒａｎｄ」毎に所定の閾値までの数のリソースのみを記録する。これにより、名前解決結果／検索結果が網羅的で無い不完全なもの（再現率が１未満）となる場合がある。
【０００６】
互いに依存関係を持たないメタ情報の組み合わせを索引語（インデックス）とした索引技術としては、シグネチャファイルがある（例えば非特許文献４参照）。シグネチャファイルは、ユーザが自己説明的な名前のように複数のメタ情報を組み合わせたものを検索条件とした場合に、単一のメタ情報を索引語とする方法と比べて、検索条件を構成する個々のメタ情報の検索結果の積をとる必要が無いという点で効率的である。
【非特許文献１】http://www.autoIDlabs.org/AUTO-ID LABS、[online]、［平例１６年７月２１日検索］、インターネット＜URL:http://www.autoIDlab.org/＞
【非特許文献２】W. Adjie-Winoto, E. Schwartz, H. Balakrishnan and J. Lilley, "The design and implementation of an intentional naming system," In Proc. of the 17th ACM Symposium on Operating Systems, Dec. 1999.
【非特許文献３】M.I.T. Computer Science and Artificial Intelligence laboratory, “Twine : Scalable International Resource Discovery for pervasive Computing environment”, [online],[平成１６年７月２１日検索]
【非特許文献４】石川他、”文書データを対象とした索引技術”, IPSJ Magazine, Vol.42 No. 10, pp.981-987, Oct. 2001.
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ところで、ユビキタスサービスを含む今後の情報流通ネットワークにおいては、扱うリソースの多様化および数の爆発的な増加を反映して、リソースの自己説明的な名前やメタ情報に基づいてリソース自身あるいはリソース情報（リソースに関する情報）の検索、所謂「逆引き」を効率的に行う仕組みが求められる。
【０００８】
固定フォーマットのＩＤに基づいて各データベースの担当（どのリソースの情報を記録・回答するか）を決定するシステムでは、メタ情報のみを用いた検索要求を想定していない。このため、この種のシステムで逆引きを行うには、全データベースへの確認が必要となり、実行時の処理効率が著しく悪化してしまう。
【０００９】
自己説明的な名前や互いに依存関係を持つメタ情報に基づく情報検索に関する研究成果が既に発表されているが、それらはスケーラビリティの観点からの問題がある。具体的には、複数のメタ情報を単純に組み合わせたものを索引語としているために、索引語（インデックス）に対応するリソースの数が、大規模システムでは膨大な数となり得る。このため、網羅的な検索結果を高速に回答することは困難である。
【００１０】
互いに依存関係を持たないメタ情報を自由に組み合わせたものを索引語とする索引技術が旧来よりあるが、これもまたユビキタスサービスに適用するにはスケーラビリティ上の問題がある。具体的には、索引語をメタ情報を組み合わせて生成する際に、結果として生成される索引語の必要性の評価を行わないために、必要以上の索引語を生成し、索引の総情報量が爆発的に増大してしまう。また、索引語によっては、対応するリソースの数が膨大となり得るために、やはり網羅的に検索できない場合がある。
【００１１】
本発明は、上記問題を解決すべくなされたもので、その目的は、検索条件に対応するリソースの数が閾値以下に限定される索引語を含む場合に、網羅的な検索結果を高速に回答することができ、索引の総情報量の増大を抑えることができるリソース検索装置、リソース検索方法およびリソース検索プログラムを提供することにある。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する逆リソース表と、前記識別ＩＤと前記リソース情報と準候補キーを対応付けて記憶しており、前記識別ＩＤあるいは前記リソース情報を受信して対応する前記準候補キーを応答する準候補キー検索手段と、ユーザからの要求メッセージを受け取る受取手段と、前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、前記準候補キー検索手段に該リソースの準候補キーを問合せ、準候補キー群を得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録する登録手段と、前記逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていた識別ＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、前記逆リソース表への再登録を行う再登録手段と、前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除する削除手段と、前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、前記削除手段によって一旦削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する検索手段と、前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段とを具備することを特徴とするリソース検索装置である。
【００１３】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する逆リソース表と、ユーザからの要求メッセージを受け取る受取手段と、前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録する登録手段と、前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成する条件作成手段と、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行う再帰的登録手段と、前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除する削除手段と、前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、前記削除手段によって一旦削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する検索手段と、前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と、を具備することを特徴とするリソース検索装置である。
【００１４】
本発明は、上記の発明において、前記リソース情報は、単に１つ以上のメタ情報の集合であるのではなく、メタ情報間の親子関係情報を含む木構造で構成されるものであり、前記条件は、リソース情報に含まれるメタ情報の部分集合だけではなく、リソース情報を構成する木構造の部分木も含むことを特徴とする。
【００１５】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する、新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表と、ユーザからの要求メッセージを受け取る受取手段と、前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記２つの逆リソース表に登録する登録手段と、前記２つの逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成する条件作成手段と、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行う再帰的登録手段と、前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記２つの逆リソース表とから該リソースに関する情報を削除する削除手段と、前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記２つの逆リソース表内の該リソースに関する情報を、前記削除手段によっていったん削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する検索手段と、前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と、ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成する逆リソース表更新手段と、を具備することを特徴とするリソース検索装置である。
【００１６】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として保持する順リソース表と、１つ以上のリソースについて、１つ以上の前記メタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として保持する逆リソース表と、ユーザからの要求メッセージを受け取る受取手段と、前記受取手段により受け取られた要求メッセージが登録要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録する登録手段と、前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成する条件作成手段と、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行う再帰的登録手段と、前記受取手段により受け取られた要求メッセージが削除要求の場合、前記要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除する削除手段と、前記受取手段により受け取られた要求メッセージが更新要求の場合、前記要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、前記削除手段によっていったん削除した後、前記登録手段によって新しい情報を登録することにより更新する更新手段と、前記受取手段により受け取られた要求メッセージが検索要求の場合、前記要求メッセージに含まれる検索条件として前記識別ＩＤが含まれる場合には、前記順リソース表から該当するリソースのリソース情報を検索し、前記識別ＩＤが含まれずに１つ以上の前記メタ情報が含まれる場合には、前記旧逆リソース表から、まず前記要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了し、それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行し、試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とする検索手段と、前記登録手段、前記削除手段、前記更新手段、前記検索手段のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する送信手段と、を具備することを特徴とするリソース検索装置である。
【００１７】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、前記識別ＩＤあるいは前記リソース情報に対応する準候補キーを得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録し、前記逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていた識別ＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、前記逆リソース表への再登録を行い、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除し、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新し、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索し、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信することを特徴とするリソース検索方法である。
【００１８】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録し、前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行い、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除し、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新し、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索し、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信することを特徴とするリソース検索方法である。
【００１９】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表に保持し、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記２つの逆リソース表に登録し、前記２つの逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行い、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記２つの逆リソース表とから該リソースに関する情報を削除し、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記２つの逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新し、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索し、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信し、ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成することを特徴とするリソース検索方法である。
【００２０】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索方法において、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持し、１つ以上のリソースについて、１つ以上の前記メタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録し、前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行い、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除し、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新し、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤが含まれる場合には、前記順リソース表から該当するリソースのリソース情報を検索し、前記識別ＩＤが含まれずに１つ以上の前記メタ情報が含まれる場合には、前記旧逆リソース表から、まず前記要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了し、それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行し、前記試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とし、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信することを特徴とするリソース検索方法である。
【００２１】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持するステップと、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、前記識別ＩＤあるいは前記リソース情報に対応する準候補キーを得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録するステップと、前記逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていた識別ＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、前記逆リソース表への再登録を行うステップと、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除するステップと、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新するステップと、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索するステップと、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、を実行させるためのリソース検索プログラムである。
【００２２】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持するステップと、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録するステップと、前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成するステップと、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行うステップと、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除するステップと、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新するステップと、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索するステップと、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、を実行させるためのリソース検索プログラムである。
【００２３】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、１つ以上のリソースについて、１つ以上の前記メタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表に保持するステップと、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記２つの逆リソース表に登録するステップと、前記２つの逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成するステップと、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行うステップと、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記２つの逆リソース表とから該リソースに関する情報を削除するステップと、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記２つの逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新するステップと、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤまたは１つ以上の前記メタ情報に基づいて、前記順リソース表もしくは前記旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索するステップと、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成するステップと、を実行させるためのリソース検索プログラムである。
【００２４】
本発明は、大量のリソースの情報について、ユーザ端末からの要求に応じて、当該リソースに固有の識別ＩＤや当該リソースに関するメタ情報から構成される１つ以上のリソース情報を登録あるいは応答するリソース検索装置のコンピュータに、１つ以上のリソースについて、前記リソースの識別ＩＤをインデックスとし、それに対応する前記リソース情報を値として順リソース表に保持するステップと、１つ以上のリソースについて、１つ以上の前記メタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持するステップと、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を前記順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを前記逆リソース表に登録するステップと、前記逆リソース表に登録できなかった前記条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成するステップと、前記作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行うステップと、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、前記順リソース表と前記逆リソース表とから該リソースに関する情報を削除するステップと、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、前記順リソース表と前記逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新するステップと、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として前記識別ＩＤが含まれる場合には、前記順リソース表から該当するリソースのリソース情報を検索し、前記識別ＩＤが含まれずに１つ以上の前記メタ情報が含まれる場合には、前記旧逆リソース表から、まず前記要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了するステップと、それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行するステップと、前記試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とするステップと、前記登録、前記削除、前記更新、前記検索のいずれかから処理の結果を受け取り、前記要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信するステップと、を実行させるためのリソース検索プログラムである。
【発明の効果】
【００２５】
この発明によれば、リソース検索装置は、１つ以上のリソースについて、リソースの識別ＩＤをインデックスとし、それに対応するリソース情報を値として順リソース表に保持する。また、１つ以上のリソースについて、１つ以上のメタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持する。ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を順リソース表に登録するとともに、識別ＩＤあるいはリソース情報に対応する準候補キー群を得た後、それら準候補キーをインデックスとするタプルの値として該識別ＩＤを逆リソース表に登録する。逆リソース表において、準候補キーであったキーが準候補キーでなくなる場合に、それまで該準候補キーに登録されていたリソースＩＤに対応するリソースについて、新たな準候補キーへ移行させるために、逆リソース表への再登録を行う。ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、順リソース表と逆リソース表とから該リソースに関する情報を削除する。ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、順リソース表と逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新する。ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として識別ＩＤまたは１つ以上のメタ情報に基づいて、順リソース表もしくは逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する。そして、上記要求メッセージに対する応答として処理結果を送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージとして送信する構成となっている。したがって、検索条件に準候補キーを含む場合、即ちリソースの数が閾値以下に限定される索引語を含む場合に、網羅的な検索結果を高速に回答することができ、索引の総情報量の増大を抑えることができるという利点が得られる。
【００２６】
また、本発明によれば、リソース検索装置は、１つ以上のリソースについて、リソースの識別ＩＤをインデックスとし、それに対応するリソース情報を値として順リソース表に保持する。また、１つ以上のリソースについて、１つ以上のメタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持する。ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを逆リソース表に登録する。逆リソース表に登録できなかった条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、登録を試みてから、再び、最も弱い条件の集合を作成する。ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、順リソース表と逆リソース表とから該リソースに関する情報を削除する。ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、順リソース表と逆リソース表内の該リソースに関する情報を、一旦削除した後、新しい情報を登録することにより更新する。ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として識別ＩＤまたは１つ以上のメタ情報に基づいて、順リソース表もしくは逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する。そして、上記要求メッセージに対する応答として処理結果を送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する構成となっている。したがって、検索条件に準候補キーを含む場合、即ちリソースの数が閾値以下に限定される索引語を含む場合に、網羅的な検索結果を高速に回答することができ、索引の総情報量の増大を抑えることができるという利点が得られる。また、さらに、内部に記憶しているリソース情報に基づいて逆リソース表を作成することが可能となる。
【００２７】
また、本発明によれば、リソース検索装置において、各リソース情報が、単に１つ以上のメタ情報の集合ではなく、メタ情報間の親子関係情報を含む木構造で構成される場合に、条件として、リソース情報に含まれるメタ情報の部分集合だけでなく、リソース情報を構成する木構造の部分木も含めることができる。したがって、様々な検索条件を設定することができ、また、木構造により絞り込んだ検索が行えるためより好適な検索結果を得ること可能となる。
【００２８】
また、本発明によれば、リソース検索装置は、１つ以上のリソースについて、リソースの識別ＩＤをインデックスとし、それに対応するリソース情報を値として順リソース表に保持し、１つ以上のリソースについて、１つ以上のメタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として新逆リソース表と旧逆リソース表と呼ばれる２つの逆リソース表に保持し、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを２つの逆リソース表に登録し、２つの逆リソース表に登録できなかった条件それぞれについて、該条件よりも強く、かつ過去にそれぞれ対応する逆リソース表に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再びそれぞれ対応する逆リソース表へ登録を行い、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、順リソース表と２つの逆リソース表とから該リソースに関する情報を削除し、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、順リソース表と２つの逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新し、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として識別ＩＤまたは１つ以上のメタ情報に基づいて、順リソース表もしくは旧逆リソース表から、それぞれ該当するリソースのリソース情報または識別ＩＤを検索する。そして、登録、削除、更新、検索のいずれかから処理の結果を受け取り、要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信し、ある一定周期ごとに順リソース表に登録されているリソース全てについて、その情報を順リソース表から読み出し、１つ１つ新逆リソース表に登録し、全て新逆リソース表に登録し終えた後、新逆リソース表を旧逆リソース表とし、それまで旧逆リソース表であったものは削除し、さらに新しく新逆リソース表を作成する構成となっている。したがって、沢山のリソース情報がデータベースから削除されたり、更新されたりした場合にも、定期的な逆リソース表の更新により、検索機能低下、すなわち、検索条件に準候補キーを含むにも関わらず検索出来なくなる現象を抑えることが出来る。
【００２９】
また、本発明によれば、リソース検索装置は、１つ以上のリソースについて、リソースの識別ＩＤをインデックスとし、それに対応するリソース情報を値として順リソース表に保持し、１つ以上のリソースについて、１つ以上のメタ惰報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースの識別ＩＤを値として逆リソース表に保持し、ユーザから登録要求があると、登録の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づき、該識別ＩＤをインデックスとするタプルの値として該リソース情報を順リソース表に登録し、該リソース情報から抽出される全ての条件の中で、最も弱い条件をインデックスとするタプルの値として該識別ＩＤを逆リソース表に登録し、逆リソース表に登録できなかった条件それぞれについて、該条件よりも強く、かつ過去に登録できたどの条件のメタ情報集合も包含しないメタ情報集合からなる条件のうち、最も弱い条件の集合を作成し、作成した条件の集合が空集合でない場合に、その全ての要素１つ１つについて、再び逆リソース表へ登録を行い、ユーザから削除要求があると、削除の要求メッセージに含まれる識別ＩＤに基づいて、順リソース表と逆リソース表とから該リソースに関する情報を削除し、ユーザから更新要求があると、更新の要求メッセージに含まれる識別ＩＤと当該リソースのリソース情報とに基づいて、順リソース表と逆リソース表内の該リソースに関する情報を、いったん削除した後、新しい情報を登録することにより更新し、ユーザから検索要求があると、検索の要求メッセージに含まれる検索条件として識別ＩＤが含まれる場合には、順リソース表から該当するリソースのリソース情報を検索し、識別ＩＤが含まれずに１つ以上のメタ情報が含まれる場合には、旧逆リソース表から、まず要求メッセージに含まれる全メタ情報をＡＮＤ演算子で結んだ条件式で検索を行い、条件が弱すぎて検索できない場合には検索失敗として処理を終了し、それまでにその条件に合致するインデックスに登録されたリソースがなかった場合、検索が成功するまで全メタ情報から１つずつ任意のメタ情報を除いてＡＮＤ演算子で結んだ検索式で繰り返し検索を試行し、試行を繰り返す中であるメタ情報を除いた条件が弱すぎて検索できなかった場合には当該メタ情報を再び検索条件に組み込んだ上で別のメタ情報を除いた条件で検索を行うこととし、検索出来た場合には、その条件で検索できた結果である識別ＩＤ集合１つ１つについて、順リソース表を使い、要求メッセージに含まれる検索条件に合致するかを検査して最終的な検索結果とする。そして、登録、削除、更新、検索のいずれかから処理の結果を受け取り、要求メッセージ送信元のユーザ端末に対し、処理の完了メッセージ、あるいは失敗メッセージを送信する構成となっている。したがって、単純な検索処理、すなわち、登録処理と同様の手順で検索を行う処理に比べ、検索処理量が劇的に小さくなり、検索時間やネットワーク負荷を小さく抑えることが出来る(具体的には、ユーザからの検索条件がａ個のメタ情報から成る場合に、前者の検索ステップ数が最悪２のａ乗回であるのに対し、後者では最悪でもａ回となる)。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の一実施形態によるリソース検索装置を図面を参照して説明する。
【実施例１】
【００３１】
図１は、本発明の実施形態によるデータベースシステムの構成を示すブロック図である。データベースシステムは、図１に示すように、インターネットなどのデータ通信ネットワーク上に存在する。本データベースシステムは、物品や情報コンテンツなど、大量のリソースの情報を効率的に保持し、また柔軟で高速な検索を可能とするものである。
【００３２】
各リソースは、上述した識別ＩＤに該当するリソースＩＤとリソース情報を持ち、リソースＩＤとは、リソースを識別するための名前、あるいはリソースのＮＷ上ないしは実世界上の位置を示す情報など、リソースを特定できる情報を意味し、リソース情報とは、種類や形状などの当該リソースに関わる属性情報の集合を意味する。リソース情報の例として、図２に物品情報を２つ示す。この例では、各物品が“属性名”＝“属性値”というフォーマットで属性情報をいくつか保持する、というものであるが、文字列などビット列で表現できる情報の集合で構成されているリソース情報ならば、同様に本データベースシステムで扱うことができる。本データベースシステムでは、ユーザが例えば図２におけるＡ〜Ｈのような属性情報のうち、１つを検索条件として入力した場合のみならず、複数の属性情報を入力した場合でも、それらのＡＮＤをとった検索条件に適合するリソースのリソースＩＤを高速に取得することができる。
【００３３】
図１において、１０１は、ユーザ端末を示し、３０１はデータベースサーバを示す。データベースサーバ３０１は上述したリソース検索装置に該当し、順リソース表、逆リソース表を備えており、閾値と呼ばれる定数を記憶している。また、上述した受信手段及び送信手段に該当するプログラム４０１と、同じく上述した登録手段、再登録手段に該当するプログラム４０２と、削除手段に該当するプログラム４０３と、更新手段に該当するプログラム４０４と、検索手段に該当するプログラム４０５と、準候補キー検索手段に該当する外部プログラム４０６が搭載されている。説明を簡単にするために、ユーザ端末およびデータベースシステムを１つずつ示したが、それぞれ複数を配置することが可能である。
【００３４】
ここで、図３は、順リソース表と逆リソース表の例を示す概念図である。順リソース表は、１つ以上のリソースについて、リソースのリソースＩＤをインデックスとし、それに対応するリソース情報を値として保持するものである。より具体的には、図３（ａ）に示すように、インデックスとしてリソースＩＤ、その値として該リソースのリソース情報を保持する。逆リソース表は、１つ以上のリソースについて、１つ以上のメタ情報を１つのインデックスとし、インデックス内のメタ情報全てをリソース情報内に含む１つ以上のリソースのリソースＩＤを値として保持するものである。より具体的には、逆リソース表の各インデックスは、図３（ｂ）に示すように、それぞれ１つ以上の属性情報から成り、値としては該当リソースＩＤの集合、すなわちインデックスである属性情報集合を自身の属性情報として持つソースのリソースＩＤの集合を値として保持する。図３においては、「製造日＝２００４年５月７日  かつ  原産国＝△△国」というインデックスがあるが、このように複数の属性情報から１つのインデックスを作ることもあるため、２つ以上の属性情報からなる属性情報集合から、インデックスとなる１つのビット列を作成する方法を決めておく必要がある。
【００３５】
この方法は、同じ属性情報集合からは一意にビット列が決定できるものでなければならない。例えば、属性情報を辞書順に並べ、つなげて１つの文字列とする方法などが考えられ、本実現例については、これ以降、属性情報集合をインデックスとして登録、あるいは検索する場合には、この方法を使うものとする。また、逆リソース表の各インデックスは、値の他にそれぞれ溢れフラグと再登録中フラグを保持する。溢れフラグは、通常、０であるが、該当リソースＩＤの数が閾値を越えた場合に１となるものである。再登録中フラグは、当該インデックスに登録されていたリソースを再登録している間、１となるものであり、検索結果の正確性を保つためのものである。
【００３６】
次に、図４は、第１のプログラム４０１の処理を示すフローチャートである。プログラム４０１は、常時起動しており、ユーザ端末から要求メッセージを受信し（ステップＳ１０１）、要求メッセージ中の命令コードより処理方法を決定し（ステップＳ１０２〜Ｓ１０４）、各処理に対応するプログラム４０２、４０３、４０４、あるいは４０５のいずれか１つのプログラムを起動してリソースＩＤやリソース情報、あるいは検索条件を渡す（ステップＳ１０５〜Ｓ１０８）。要求メッセージには、登録要求メッセージ、削除要求メッセージ、更新要求メッセージ、および検索要求メッセージの４種類が存在し、その種類を示す命令コードの他に、登録要求メッセージと更新要求メッセージには、リソースＩＤとリソース情報、削除要求メッセージには、リソースＩＤ、また検索要求メッセージには、検索条件がそれぞれ含まれている。ここで検索条件とは、リソースＩＤもしくは１つ以上の属性情報から成り、ユーザが検索したいリソースを指定するものである。
【００３７】
登録要求メッセージに対しては、プログラム４０２が動作する。
第２のプログラム４０２は、プログラム４０１がユーザ端末から登録要求メッセージを受け取った場合、プログラム４０１によって起動される。プログラム４０２は、該リソースＩＤと該リソース情報とを本データベースシステムに登録する。まず、該リソースＩＤが順リソース表のインデックスに既に存在するかどうかを調べ、存在する場合には、要求メッセージの送信元であるユーザ端末に登録失敗メッセージを送信し、プログラムを終了する。一方、該リソースＩＤが順リソース表のインデックスに存在していない場合には、順リソース表に該リソースＩＤと該リソース情報とを新たに登録し、続けて逆リソース表にも登録する。
【００３８】
逆リソース表への登録においては、まず、外部プログラム４０６に該リソースＩＤとリソース情報とを渡し、答えとして１つ以上の準候補キーのリストを受け取る。なお、準候補キーとは、値としてＴ個以下のリソースＩＤを持つインデックスのうち、インデックス中のメタ情報が１つでも欠けると、値となるリソースＩＤがＴ個以上になってしまうものを言う。そのため、登録されているリソース情報の種類や量の変化に伴い、準候補キーであったインデックスが準候補キーでなくなる、あるいは逆に準候補キーでなかったものが準候補キーになる、という変化が起こる。このとき、今まで準候補キーであったが、該リソースの登録のために準候補キーでなくなるもののリストも同時に受け取る。受け取った準候補キーのリストと準候補キーでなくなるもののリストとに対し、まず、準候補キーのリストについては、その各要素をそれぞれインデックスとするタプルへ、該リソースＩＤがその値となるよう逆リソース表へ登録する。
【００３９】
準候補キーでなくなるもののリストについては、その各要素の準候補キーをインデックスとするタプルに、既に登録されているリソースＩＤ全てについて、再登録を行った後、該タプルから削除し、さらに該タプルの溢れフラグを立てておく。再登録では、順リソース表から該リソースＩＤに対応するリソース情報を取得し、リソースＩＤとリソース情報とをセットにして、再帰的に、このプログラム４０２を使って再び登録を行う。逆リソース表への登録が完了した後、要求メッセージの送信元であるユーザ端末に登録完了メッセージを送信する。
【００４０】
次に、削除要求メッセージに対しては、プログラム４０３が動作する。
第３のプログラム４０３は、プログラム４０１がユーザ端末から削除要求メッセージを受け取った場合、プログラム４０１によって起動される。プログラム４０３は、該リソースＩＤとそれに対応するリソース情報とを本データベースシステムから削除する。まず、該リソースＩＤが順リソース表のインデックスに既に存在するかどうかを調べ、存在しない場合には、要求メッセージの送信元であるユーザ端末に削除失敗メッセージを送信し、プログラムを終了する。一方、該リソースＩＤが順リソース表のインデックスに存在している場合には、その値である該リソースＩＤに対するリソース情報を取得した後、順リソース表から該インデックスとその値を削除する。次に、逆リソース表から削除する。
【００４１】
逆リソース表から削除する際には、まず、外部プログラム４０６に該リソースＩＤとリソース情報とを渡し、答えとして１つ以上の準候補キーのリストを受け取る。次に、このリストにある準候補キーそれぞれについて、これをインデックスとするタプルから、該リソースＩＤを削除する。逆リソース表からの削除が完了した後、要求メッセージの送信元であるユーザ端末に削除完了メッセージを送信し、プログラムを終了する。
【００４２】
次に、更新要求メッセージに対しては、プログラム４０４が動作する。
第４のプログラム４０４は、プログラム４０１がユーザ端末から更新要求メッセージを受け取った場合、プログラム４０１によって起動される。更新は、まず、古い情報の削除を行い、改めて新しい情報を登録することにより行う。プログラム４０４は、プログラム４０３とプログラム４０２とを起動してこれを実現する。
【００４３】
次に、検索要求メッセージに対しては、プログラム４０５が動作する。
第５のプログラム４０５は、プログラム４０１がユーザ端末から検索要求メッセージを受け取った場合、プログラム４０１によって起動される。プログラム４０５は、本データベースシステムから、検索条件に合致するリソースＩＤもしくはリソース情報を検索するプロセスを実行する。まず、検索条件を調べ、リソースＩＤが含まれている場合には、順リソース表から該リソースに対応するリソース情報を検索し、検索結果であるリソース情報を含めた検索完了メッセージを要求メッセージの送信元であるユーザ端末に送信する。
【００４４】
このとき、検索結果は、空集合である場合もある。そして、リソースＩＤが含まれていない場合には、逆リソース表から対応するリソースＩＤ群を検索し、検索結果であるリソースＩＤ群を含めた検索完了メッセージを、要求メッセージの送信元であるユーザ端末に送信する。このときも検索結果は、空集合である場合がある。逆リソース表から検索する際には、まず、外部プログラム４０６にリソース情報を渡し、答えとして１つ以上の準候補キーのリストを受け取る。次に、このリストにある準候補キーそれぞれについて、これをインデックスとするタプルの溢れフラグが立っているかどうかを調べる。そして、立っていないものが見つかった時点で、その処理を終了し、溢れフラグが立っていなかったタプルに登録されているリソースＩＤ全てについて、検定を行う。検定処理では、各リソースＩＤについて、該リソースＩＤに対応するリソース情報を順リソース表から取得した後、このリソース情報にプログラム４０１から受け取った検索条件に含まれる属性情報が全て含まれているかを検査し、含まれているならば、合格と見なす。一方、１つでも含まれていない属性情報がある場合には、不合格とみなす。そして、この検定に合格したリソースＩＤの集合を、検索結果とする。
【実施例２】
【００４５】
次に、本発明の実施例２について説明する。図５は、本実施例２によるデータベースシステムの構成を示すブロック図である。図示するように、インターネットなどのデータ通信ネットワーク上に実施例１とほぼ同様の構成のデータベースシステムがある。ただし、実施例１のものと異なり、外部プログラム４０６を利用しない。
【００４６】
図５において、１０１はユーザ端末を示し、３０１はデータベースサーバを示す。データベースサーバ３０１には、順リソース表、逆リソース表、閾値と呼ばれる定数、次の５つのプログラム４０１、４０２、４０３、４０４、４０５が搭載されている。順リソース表と逆リソース表、プログラム４０１は、実施例１のものと同じである。実施例１と同様に、説明を簡単にするために、ユーザ端末およびデータベースシステムを１つずつ示したが、それぞれ複数を配置することが可能である。
【００４７】
まず、登録要求メッセージに対しては、プログラム４０２が動作する。
ここで、図６は、第２のプログラム４０２の処理を示すフローチャートである。プログラム４０１がユーザ端末から登録要求メッセージを受け取った場合、プログラム４０１は、プログラム４０２を起動する。プログラム４０２は、該リソースＩＤと該リソース情報とを本データベースシステムに登録する。まず、該リソースＩＤが順リソース表のインデックスに既に存在するかどうかを調べ（ステップＳ２０１）、存在する場合には、要求メッセージの送信元であるユーザ端末に登録失敗メッセージを送信し（ステップＳ２０２）、プログラムを終了する。一方、該リソースＩＤが順リソース表のインデックスに存在していない場合には、順リソース表に該リソースＩＤと該リソース情報とを新たに登録し（ステップＳ２０３）、次に、逆リソース表に登録する（ステップＳ２０４）。図７に、リソース情報を逆リソース表へ登録する際の処理フローを示す。これについては後述する。逆リソース表への登録が完了した後、要求メッセージの送信元であるユーザ端末に登録完了メッセージを送信する（ステップＳ２０５）。登録完了メッセージに、後述する成功リスト内の情報を含めることにより、どのインデックスに登録したかをユーザに通知する。
【００４８】
次に、前述した図７に示す、リソースを逆リソース表へ登録する際の処理フローについて説明する。まず、該リソース情報に含まれる属性情報を１つずつばらし、それぞれに該リソースＩＤを加えて登録情報のリストとし、各登録情報を候補リストへ追加する（ステップＳ３０１）。登録情報とは、逆リソース表において１つのインデックスとなる属性情報の集合と、その値となるリソースＩＤとから成るものである。候補リストは、逆リソース表への登録を試みる登録情報のリストである。
【００４９】
次に、失敗リストに入っている要素の属性情報数を示す値Ａを０に設定する（ステップＳ３０２）。失敗リストとは、登録に失敗した登録情報を一時的に保持しておくリストである。次に、候補リストを調べ（ステップＳ３０３）、空である場合には登録を終了する。一方、空でない場合には、候補リストから先頭の要素を１つ取り出し（ステップＳ３０４）、この要素が持つ属性情報集合が、成功リストの要素が保持する属性情報集合を含まないか、検査を行い（ステップＳ３０５）、含む場合には、ステップＳ３０３に戻る。一方、含まない場合には、この候補リストから取り出した要素、すなわち登録情報を、逆リソース表に登録することを試みる（ステップＳ３０６）。図８に、登録情報を逆リソース表に登録する際の処理フローを示す。これについては後述する。
【００５０】
そして、登録に成功した場合には、該登録情報を成功リストに追加し（ステップＳ３０８）、ステップＳ３０３に戻る。一方、登録に失敗した場合には、該登録情報が含む属性情報集合の要素数をＡと比較する（ステップＳ３０９）。そして、Ａよりも大きい場合には、失敗リストの要素を全て削除する（ステップＳ３１０）。その後、該登録情報を失敗リストに追加し（ステップＳ３１１）、Ａの値を該登録情報集合の要素数にセットし（ステップＳ３１２）、そしてステップＳ３０３に戻る。
【００５１】
一方、該登録情報が含む属性情報集合の要素数がＡと同じかＡより小さい場合には、失敗リストに含まれている要素１つ１つをそれぞれ該登録情報と組み合わせ、それが既に候補リストに含まれていなければ、新しい登録情報として候補リストに追加する（ステップＳ３１３〜Ｓ３１９）。さらに、属性情報集合要素数の昇順になるよう、候補リストの並び替えを行い（ステップＳ３２０）、その後、失敗リストに該登録情報を追加し（ステップＳ３２１）、ステップＳ３０３に戻る．
【００５２】
次に、前述した図８に示す、登録情報を逆リソース表に登録する際の処理フローについて説明する。まず、該登録情報の属性情報集合が既に逆リソース表のインデックスにあるかどうかを調べ（ステップＳ４０１）、既存でない場合には新しいインデックスとして追加し（ステップＳ４０２）、その値として該登録情報のリソースＩＤを登録し（ステップＳ４０３）、そして、登録を成功とみなして登録成功フラグを１とし（ステップＳ４０４）、登録処理を終了する。
【００５３】
一方、逆リソース表のインデックスに既存であった場合には、まず、該インデックスの溢れフラグを調べ（ステップＳ４０５）、溢れていた場合には、さらに再登録中フラグを調べる（ステップＳ４０６）。そして、再登録中でなかった場合には、登録失敗と見なし（ステップＳ４０８）、処理を終了する。一方、再登録中であった場合には、値であるリソースＩＤを該インデックスの値に追加し（ステップＳ４０７）、その後、登録失敗と見なして処理を終了する。
【００５４】
また、ステップＳ４０５において、溢れフラグが０であった場合には、次に、既に値として登録されていたリソースＩＤの数を閾値と比較する（ステップＳ４０９）。そして、等しくない場合には、値であるリソースＩＤ集合に該登録情報のリソースＩＤが含まれているかを調べ（ステップＳ４１０）、含まれている場合には、ステップＳ４０４へ、含まれていない場合には、ステップＳ４０３へ進む。
【００５５】
既に値として登録されていたリソースＩＤの数が閾値と等しい場合には、登録を失敗と見なし、溢れフラグ、再登録中フラグともに１にセットする（ステップＳ４１１）。さらに、リソースＩＤを該インデックスの値に追加し（ステップＳ４１２）、その後、閾値と同じ数だけある、既に登録されていたリソースＩＤについて、再登録処理を行う（ステップＳ４１３）。
【００５６】
上述した、閾値と同じだけあるリソースＩＤ集合を再登録する際の処理フローを図９に示す。図９は、閾値と同じだけあるリソースＩＤ集合を再登録する際の処理フローを示している。各リソースＩＤの再登録においては、まず、該リソースＩＤのリソース情報を順リソース表から取得する（ステップＳ５０２）。次に、登録プロセスであるプログラム４０２を起動し、該リソースＩＤと該リソース情報とを渡す（ステップＳ５０３）。閾値と同じだけあるリソースＩＤ全てに対してこれを行い（ステップＳ５０１〜Ｓ５０５）、その後、該リソース集合が元々入っているインデックスの再登録中フラグを０にセットし（ステップＳ５０６）、また、そのリソース集合を含む値全てを削除し（ステップＳ５０７）、処理を終了する。
【００５７】
プログラム４０２が動作することにより、リソースの登録を行うことができる。例えば、図１０に示した５つの物品群を、閾値を２として順次登録する場合を考える。簡単のため、図１０では、属性情報を簡単な記号で示したが、図２のような文字列でもよい。図１０におけるリソース情報のうち、物品１から物品３までを登録した後の順リソース表、逆リソース表の様子を図１１に示す。ここに、さらに物品４を登録した場合の順リソース表、逆リソース表の様子を図１２に示す。物品４を登録すると、「Ａ２＝Ｖ２」のインデックスに対する値が、物品１、物品２、物品４の３つとなり、閾値を越えるために溢れフラグが立ち、既に登録されていた物品１、物品２については再登録が行われている。さらに、物品５を登録した場合の順リソース表、逆リソース表の様子を図１３に示す。物品５を登録すると、さらに「Ａ４＝Ｖ４」のインデックスに対する値も溢れ、既に登録されていた物品１、物品４は再登録される。この再登録においては、「Ａ２＝Ｖ２」のインデックスヘの登録と「Ａ４＝Ｖ４」のインデックスヘの登録において登録が失敗するため、それらを組み合わせた「Ａ２＝Ｖ２Ａ４＝Ｖ４」への登録が行われ、新たに「Ａ２＝Ｖ２Ａ４＝Ｖ４」のインデックスが生成されていることが分かる。
【００５８】
次に、削除要求メッセージに対しては、プログラム４０３が動作する。
第３のプログラム４０３の処理フローを図１４に示す。プログラム４０１がユーザ端末から削除要求メッセージを受け取った場合、プログラム４０１は、このプログラム４０３を起動する。プログラム４０３は、該リソースＩＤとそれに対応するリソース情報とを本データベースシステムから削除する。まず、該リソースＩＤが順リソース表のインデックスに既に存在するかどうかを調べ（ステップＳ６０１）、存在しない場合には、要求メッセージの送信元であるユーザ端末に削除失敗メッセージを送信し（ステップＳ６０２）、プログラムを終了する。一方、該リソースＩＤが順リソース表のインデックスに存在している場合には、その値である該リソースＩＤに対するリソース情報を取得し（ステップＳ６０３）、その後、順リソース表から該インデックスとその値を削除する（ステップＳ６０４）。次に、逆リソース表から削除する（ステップＳ６０５）。図１５に、リソース情報を逆リソース表から削除する際の処理フローを示す。これについては後述する。そして、逆リソース表からの削除が完了した後、要求メッセージの送信元であるユーザ端末に削除完了メッセージを送信し（ステップＳ６０６）、プログラムを終了する。
【００５９】
次に、上述した図１５に示す、リソースを逆リソース表から削除する際の処理フローについて説明する。まず、該リソース情報に含まれる属性情報を１つずつばらし、それぞれに該リソースＩＤを加えて削除情報のリストとし、各削除情報を候補リストへ追加する（ステップＳ７０１）。削除情報とは、逆リソース表において１つのインデックスとなっている属性情報の集合と、その値となるリソースＩＤとから成るものである。また、候補リストは、逆リソース表からの削除を試みる削除情報のリストである。
【００６０】
次に、失敗リストに入っている要素の属性情報数を示す値Ａを０に設定する（ステップＳ７０２）。ここで、失敗リストとは、削除に失敗した削除情報を一時的に保持しておくリストである。次に、候補リストを調べ（ステップＳ７０３）、空である場合には削除を終了する。一方、空でない場合には、候補リストから先頭の要素を１つ取り出し（ステップＳ７０４）、この要素が持つ属性情報集合が、成功リストの要素が保持する属性情報集合を含まないか、検査を行い（ステップＳ７０５）、含む場合には、ステップＳ７０３に戻る。一方、含まない場合には、この候補リストから取り出した要素、すなわち削除情報を、逆リソース表から削除することを試みる（ステップＳ７０６）。図１６に、削除情報を逆リソース表から削除する際の処理フローを示す。これについては後述する。
【００６１】
そして、削除に成功した場合には、該削除情報を成功リストに追加し（ステップＳ７０８）、ステップＳ７０３に戻る。一方、削除に失敗した場合には、該削除情報が含む属性情報集合の要素数をＡと比較し（ステップＳ７０９）、Ａよりも大きい場合には、失敗リストの要素を全て削除する（ステップＳ７１０）。その後、該削除情報を失敗リストに追加し（ステップＳ７１１）、Ａの値を該削除情報集合の要素数にセットし（ステップＳ７１２）、そしてステップＳ７０３に戻る。
【００６２】
また、該削除情報が含む属性情報集合の要素数がＡと同じかＡより小さい場合には、失敗リストに含まれている要素１つ１つをそれぞれ該削除情報と組み合わせ、それが既に候補リストに含まれていなければ、新しい削除情報として候補リストに追加する（ステップＳ７１３〜Ｓ７１９）。さらに、属性情報集合要素数の昇順になるよう、候補リストの並び替えを行い（ステップＳ７２０）、その後、失敗リストに該削除情報を追加し（ステップＳ７２１）、ステップＳ７０３に戻る。
【００６３】
次に、上述した削除情報を逆リソース表から削除する際の処理フローについて図１６を参照して説明する。まず、該削除情報の属性情報集合に対応する逆リソース表のインデックスの溢れフラグを調べ（ステップＳ８０１）、０である場合には、値から該リソースＩＤを削除し（ステップＳ８０２）、削徐を成功とみなし（ステップＳ８０３）、削除処理を終了する。一方、Ｓ８０１において溢れフラグが１であった場合には、さらに再登録中フラグを調べ（ステップＳ８０４）、１であった場合には、０になるまで持つ。そして、再登録中フラグが０であるか、あるいは０になった場合に、削除を失敗とみなして削除成功フラグを０にセットし（ステップＳ８０５）、削除処理を終了する。
【００６４】
次に、更新要求メッセージに対しては、プログラム４０４が動作する。
更新は、まず、古い情報の削除を行い、改めて新しい情報を登録することにより行う。プログラム４０４は、プログラム４０３とプログラム４０２とを起動してこれを実現する。
【００６５】
また、検索要求メッセージに対しては、プログラム４０５が動作する。
ここで、第５のプログラム４０５の処理フローを図１７に示す。プログラム４０１がユーザ端末から検索要求メッセージを受け取った場合、プログラム４０１は、このプログラム４０５を起動する．プログラム４０５は、本データベースシステムから、検索条件に合致するリソースＩＤもしくはリソース情報を検索するプロセスを実行する。まず、検索条件を調べ（ステップＳ９０１）、リソースＩＤが含まれている場合には、順リソース表から該リソースに対応するリソース情報を検索し（ステップＳ９０２）、検索結果であるリソース情報を含めた検索完了メッセージを要求メッセージの送信元であるユーザ端末に送信する（ステップＳ９０３）。このとき、検索結果は、空集合である場合もある。
【００６６】
一方、リソースＩＤが含まれていない場合には、逆リソース表から対応するリソースＩＤ群を検索し（ステップＳ９０４）、検索結果であるリソースＩＤ群を含めた検索完了メッセージ、あるいは検索失敗メッセージを、要求メッセージの送信元であるユーザ端末に送信する（ステップＳ９０５）。このときも、検索結果は、空集合である場合がある。検索が失敗した場合には、ユーザ端末にて、検索条件の変更や追加を促す表示を行い、ユーザビリティを向上させることも可能である。
【００６７】
次に、上述した、逆リソース表から検索する際の処理フローについて説明する。逆リソース表から検索する際の処理フローを図１８に示す。
まず、該検索条件に含まれる属性情報を１つずつばらしてそれぞれ検索情報とし、各検索情報を候補リストへ追加する（ステップＳ１００１）。ここで、検索情報とは、逆リソース表において１つのインデックスとなっている可能性がある属性情報の集合から成るものである。また、候補リストは、逆リソース表からの検索を試みる検索情報のリストである。次に、失敗リストに入っている要素の属性情報数を示す値Ａを０に設定する（ステップＳ１００２）。ここで、失敗リストとは、検索に失敗した検索情報を一時的に保持しておくリストである。次に、候補リストを調べ（ステップＳ１００３）、空である場合には、検索処理は失敗したと見なし（ステップＳ１００４）、検索を終了する。一方、空でない場合には、候補リストから先頭の要素を１つ取り出し（ステップＳ１００５）、逆リソース表から検索することを試みる（ステップＳ１００６）。図１９に、検索情報を逆リソース表から検索する際の処理フローを示す。これについては後述する。
【００６８】
そして、検索に成功した場合には、検索結果の検定を行い（ステップＳ１００８）、検索を終了する。図２０に、検索結果を検定する際の処理フローを示す。これについては後述する。一方、検索に失敗した場合には、該検索情報が含む属性情報集合の要素数をＡと比較し（ステップＳ１００９)、Ａよりも大きい場合には、失敗リストの要素を全て削除する（ステップＳ１０１０）。その後、該検索情報を失敗リストに追加し（ステップＳ１０１１）、Ａの値を該検索情報集合の要素数にセットし（ステップＳ１０１２）、ステップＳ１００３に戻る。
【００６９】
また、該検索情報が含む属性情報集合の要素数がＡと同じかＡより小さい場合には、失敗リストに含まれている要素１つ１つをそれぞれ該検索情報と組み合わせ、それが既に候補リストに含まれていなければ、新しい検索情報として候補リストに追加する（ステップＳ１０１３〜Ｓ１０１９）。さらに、属性情報集合要素数の昇順になるよう、候補リストの並び替えを行い（ステップＳ１０２０）、その後、失敗リストに該検索情報を追加し（ステップＳ１０２１)、ステップＳ１００３に戻る。
【００７０】
ここで条件とは、リソース情報を構成するメタ情報集合の部分集合を指し、該リソースの検索条件となりえるものであるため、条件と呼ぶ。ある条件のメタ情報集合がもう１つの条件のメタ情報集合を包含する場合、前者は後者よりも検索における絞り込みの程度が強いため、前者は後者よりも強い条件であると言う。包含関係が分からない場合には、条件の強弱を比較する事はできない。そのため、最も弱い条件は必ずしも１つには決まらず、複数となりうる。複数となった場合、その最も弱い条件の集合の各要素の登録順は問わない。また、あるリソースから抽出される条件の登録を試みるとは、該リソースのリソース情報を構成するメタ情報集合のある部分集合を条件とし、該条件をインデックスとするタプルへ該リソースのリソースＩＤを値として保持させることを言う。ただし、１つのタプルが値として保持するリソースＩＤはＴ個までであり、既に登録されているリソースＩＤがＴ個未満である場合には、新しいリソースＩＤを追加登録することができ、登録成功となるが、既にＴ個登録されていた場合には新たなリソースＩＤをさらに登録することはできず、登録は失敗となる。
【００７１】
なお、上述した図１８では、登録処理と同じように、弱い条件から試行する動作を表したが、検索の場合には必ずしも弱い条件から試行する必要はなく、逆に強い条件から試行したり、検索条件から抽出される条件全てを一斉に検索したりすることもできる。一斉に検索するような場合には、検索結果が複数返ってくるのを防ぐため、まず、検索結果を持っているかどうかの問い合わせをし、持っているという返事が返ってきたならば、その後、検索結果を持っているタプルの１つを選び、検索結果をそこだけから得る、ということが考えられる。
【００７２】
次に、上述した、検索情報を逆リソース表から検索する際の処理フローについて図１９を参照して説明する。まず、検索情報が逆リソース表のインデックスとして既に存在するかを調べ（ステップＳ１１０１）、存在していない場合には、検索結果を空とし（ステップＳ１１０２）、検索を成功とみなして（ステップＳ１１０３）、処理を終了する。一方、逆リソース表のインデックスとして既存である場合には、溢れフラグと再登録中フラグとを調べ（ステップＳ１１０４、Ｓ１１０５）、それぞれ１、０である場合には、検索を失敗とみなして（ステップＳ１１０６）、処理を終了する。それ以外の場合には、該インデックスの値を取得してこれを検索結果とし（ステップＳ１１０７）、検索を成功とみなして（ステップＳ１１０８）、処理を終了する。
【００７３】
次に、上述した、検索結果を検定する際の処理フローについて図２０を参照して説明する。まず、検索結果の数をＭとし（ステップＳ１２０１）、検索結果の数であるＭが０であるか、すなわち、検索結果に含まれるリソースＩＤが０であるか否かを判断する（ステップＳ１２０２）。そして、検索結果に含まれるリソースＩＤが０個である場合には、即処理を終了する。一方、リソースＩＤが１つ以上含まれる場合には、各リソースＩＤについて、該リソースＩＤに対応するリソース情報を順リソース表から取得し（ステップＳ１２０４）、その後、このリソース情報にプログラム４０１から受け取った検索条件に含まれる属性情報が全て含まれているかを検査し（ステップＳ１２０５）、含まれているならば、合格と見なす。一方、１つも含まれていない属性情報がある場合には、不合格とみなして検索結果から削除する（ステップＳ１２０６）。
【実施例３】
【００７４】
次に、実施例３について説明する。本実施例３においても、インターネットなどのデータ通信ネットワーク上に実施例２と同じ構成のデータベースシステムがある。ただし、実施例２とは異なり、実施例３では、ＸＭＬに代表される木構造を持った情報をリソース情報として扱うことができる。リソース情報内の属性情報間に親子関係がある場合に、実施例２においては、その関係をデータベースに取り込むことができず、当然、ユーザも属性情報間の関係を使った検索条件を指定することはできない。これに対して、本実施例３では、そうした親子関係をデータベースに保持し、ユーザにより、１つ以上の属性情報と、それらの親子関係とを指定することができるようになっている。
【００７５】
実施例３のデータベースシステムは、実施例２の構成とほとんど同じであるが、逆リソース表に対するリソースの登録処理、削除処理、検索処理のそれぞれステップＳ３１３〜Ｓ３２１、ステップＳ７１３〜Ｓ７２１、ステップＳ１０１３〜Ｓ１０２１の代わりに、実施例３では、図２１に示すステップＳ１３０１〜Ｓ１３１３の処理を行う。まず、失敗リストに含まれている要素１つ１つをそれぞれ該登録情報と組み合わせ、それが既に候補リストに含まれていなければ、新しい登録情報として候補リストに追加する（ステップＳ１３０１〜Ｓ１３０７)。実施例３においては、さらに、該登録情報内で属性情報間の親子関係が完全には記述されていない場合に（ステップＳ１３０８）、その構造記述を一箇所だけ追加した登録情報を生成し（ステップＳ１３０９）、それが既に候補リストに含まれていなければ（ステップＳ１３１０）、新しい登録情報として候補リストに追加する（ステップＳ１３１１）。次に、候補リスト中の要素について、条件としての強さの昇順になるよう、並び替えを行い（ステップＳ１３１２）、その後、失敗リストに該登録情報を追加する（ステップＳ１３１３）。
【実施例４】
【００７６】
次に、実施例４について説明する。図２２は、本実施例４によるデータベースシステムの構成を示すブロック図である。図示するように、インターネットなどのデータ通信ネットワーク上に実施例２とほぼ同様の構成のデータベースシステムがある。ただし、実施例２のものと異なり、逆リソース表が新旧２つ存在し、それぞれ新逆リソース表、旧逆リソース表と呼ぶこととする。また、プログラム４０２、４０３、４０５の動作がやや異なる。また、プログラム４０７と逆リソース表更新周期と呼ばれる定数が新たに加えられている。
【００７７】
図２２において、１０１はユーザ端末を示し、３０１はデータベースサーバを示す。データベースサーバ３０１には、順リソース表、旧逆リソース表、新逆リソース表、閾値と呼ばれる定数、逆リソース表更新周期と呼ばれる定数、次の６つのプログラム４０１、４０２、４０３、４０４、４０５、４０７が搭載されている。順リソース表、新旧２つの逆リソース表、プログラム４０１、４０４は、実施例２のものと同じである。実施例２と同様に、説明を簡単にするために、ユーザ端末およびデータベースシステムを１つずつ示したが、それぞれ複数を配置することが可能である。
【００７８】
まず、登録要求メッセージに対しては、プログラム４０２が動作する。ここで、図２３は、第２のプログラム４０２の処理を示すフローチャートである。実施例２のもの(図６)とほぼ同様であるが、逆リソース表への登録処理を、新旧２つの逆リソース表へそれぞれ行うようになっている点で異なる。それぞれの逆リソース表への登録方法は、実施例２や実施例３と同様である。
【００７９】
次に、削除要求メッセージに対しては、プログラム４０３が動作する。
第３のプログラム４０３の処理フローを図２４に示す。実施例２のもの(図１４)とほぼ同様であるが、逆リソース表からの削除処理を、新旧２つの逆リソース表からそれぞれ行うようになっている点で異なる。それぞれの逆リソース表からの削除方法は、実施例２や実施例３と同様である。
【００８０】
次に、検索要求メッセージに対しては、プログラム４０５が動作する。
第５のプログラム４０５の処理フローを図２５に示す。実施例２のもの(図１７)と同様であるが、逆リソース表からの検索処理においては、新旧２つの逆リソース表のうち、旧逆リソース表を用いる。
【００８１】
第７のプログラム４０７の処理フローを図２６に示す。プログラム４０７は、常時起動されており、まずタイマーをリセットし(ステップＳ１７０１)、逆リソース表更新周期が経過するまで待つ(ステップＡ１７０２)。逆リソース表更新周期が経過し、再びタイマーをリセットした(ステップＳ１７０３)後、順リソース表から１行ずつリソース情報を取り出し、新逆リソース表に登録する(ステップＳ１７０４〜Ｓ１７０６)。逆リソース表への登録の仕方は前述のものと同様である。順リソース表に登録されているリソース全てを新逆リソース表に登録し終えたら、旧逆リソース表を削除し、新逆リソース表を旧逆リソース表に置き換える(ステップＳ１７０７)。新たに新進リソース表のための領域を準備し(ステップＳ１７０８)、再び進リソース表更新周期が経過するのを待つ、ということを繰り返す。
【実施例５】
【００８２】
実施例５について説明する。本実施例５においても、インターネットなどのデータ通信ネットワーク上に実施例４と同じ構成のデータベースシステムがある。ただし、実施例５では、検索要求メッセージに対するプログラム４０５の動作が実施例４のものとは異なる。
【００８３】
本実施例５におけるプログラム４０５の処理フローを図２７に示す。プログラム４０５は、本データベースシステムから、検索条件に合致するリソースＩＤもしくはリソース情報を検索するプロセスを実行する。
【００８４】
まず、検索条件を調べ（ステップＳ１８０１）、リソースＩＤが含まれている場合には、順リソース表から該リソースに対応するリソース情報を検索し（ステップＳ１８０２）、該当するリソース情報があった場合には、検索結果であるリソース情報を含めた検索完了メッセージを要求メッセージの送信元であるユーザ端末に送信する（ステップＳ１８０４）。該当するリソース情報がなかった場合には、指定された検索条件に該当するリソースはなかったことを意味するメッセージをユーザ端末に送信する（ステップＳ１８０５）。
【００８５】
一方、リソースＩＤが含まれていない場合には、確定要素リストを空集合、検査要素をＮＵＬＬに初期化し、不確定要素リストに検索条件に含まれる要素全てを入れる（ステップＳ１８０６）。次に確定要素リスト、不確定要素リスト内の全要素をＡＮＤで結合した条件で旧逆リソース表から検索を行う。本実施例５では、プログラム４０５の動作が異なる以外は、実施例４と同じ構成のデータベースシステムで動作するものであるが、実施例２や３と同じ構成でも動作し、同じ効果が得られる。この場合には、データベースシステム上には逆リソース表は１つしかなく、ステップＳ１８０７においては、この唯一の逆リソース表から検索すればよい。
【００８６】
逆リソース表から検索した結果、検索成功フラグが１であった場合には、検索結果の検査を行い（ステップＳ１８０９）、検査に合格したリソースが存在した場合には、その検査に合格したリソースＩＤ群を含めた検索完了メッセージをユーザ端末に送信する（ステップＳ１８１１）。検査に合格したリソースが存在しなかった場合には、指定された検索条件に該当するリソースは存在しなかったことを意味するメッセージをユーザ端末に送信する（ステップＳ１８０５）。検査の方法は、実施例４と同様である。
【００８７】
逆リソース表から検索した結果、検索成功フラグが０であった場合には、検査要素がＮＵＬＬかどうかを調べ（ステップＳ１８１３）、ＮＵＬＬであった場合には、検索条件が弱すぎるため、閾値以下の個数に絞られないことを意味するメッセージをユーザ端末に送信する（ステップＳ１８１４）。検査要素がＮＵＬＬでなかった場合には、検査要素を確定要素リストに加え（ステップＳ１８１５）、不確定要素リストが空集合であるかどうかを調べる（ステップＳ１８１６）。空集合であった場合には、指定された検索条件に該当するリソースは存在しなかったことを意味するメッセージをユーザ端末に送信する（ステップＳ１８０５）。
【００８８】
不確定要素リストが空集合でなかった場合には、不確定要素リストの中からランダムに１要素を抜き出し、検査要素とし（ステップＳ１８１７）、ステップＳ１８０７に戻る。
逆リソース表から検索した結果、検索成功フラグが０でも１でもなかった場合には、上述のステップＳ１８１６に進む。
【００８９】
次に、上述した、逆リソース表から検索する際の処理フローについて図２８を参照して説明する。まず、検索条件が逆リソース表のインデックスとして既に存在するかを調べ（ステップＳ１９０１）、存在していない場合には、検索成功フラグを−１として（ステップＳ１９０２）処理を終了する。一方、逆リソース表のインデックスとして既存である場合には、溢れフラグと再登録中フラグを調べ（ステップＳ１９０３、Ｓ１９０４）、それぞれ１，０である場合には、検索成功フラグに０を代入して（ステップＳ１９０５）処理を終了する。それ以外の場合には、該インデックスの値を取得してこれを検索結果とし（ステップＳ１９０６）、検索成功フラグを１として（ステップＳ１９０７）処理を終了する。
【００９０】
上述した実施形態によれば、１つ以上のメタ情報を自由に組み合わせたものを索引語とし、索引語に対応するリソースの数がある閾値以下に抑えられることを保障する仕組みを具えることで、検索条件に対応するリソースの数が閾値以下に限定される索引語、すなわち準候補キーを含む場合に、網羅的な検索結果を高速に回答することができる。
また、同時に、索引の構築において、生成される索引語の必要性の評価を行い、且つ対応するリソースの数が閾値以下に限定されない索引語については対応するリソースの情報を消去することにより、索引の総情報量の増大を抑えることができる。
【００９１】
上述のデータベースサーバ３０１は内部に、コンピュータシステムを有している。そして、上述したデータベースサーバ３０１の処理過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【図面の簡単な説明】
【００９２】
【図１】本発明の実施例１のシステムの基本構成を示すブロック図である。
【図２】リソース情報の例を示す概念図である。
【図３】順リソース表（上）と逆リソース表（下）の例を示す概念図である。
【図４】プログラム４０１の処理フローを示すフローチャートである。
【図５】実施例２のシステムの基本構成を示すブロック図である。
【図６】プログラム４０２の処理フローを示すフローチャートである。
【図７】逆リソース表へのリソースの登録処理フローを示すフローチャートである。
【図８】逆リソース表への登録情報の登録処理フローを示すフローチャートである。
【図９】再登録処理フローを示すフローチャートである。
【図１０】登録するリソース情報を示す概念図である。
【図１１】図１０に示したリソース情報のうち、物品１〜３を登録した後の順リソース表（上）と逆リソース表（下）を示す概念図である。
【図１２】図１０に示したリソース情報のうち、物品１〜４を登録した後の順リソース表（上）と逆リソース表（下）を示す概念図である。
【図１３】図１０に示したリソース情報を登録した後の順リソース表（上）と逆リソース表（下）を示す概念図である。
【図１４】プログラム４０３の処理フローを示すフローチャートである。
【図１５】逆リソース表からのリソースの削除処理フローを示すフローチャートである。
【図１６】逆リソース表からの１削除情報の削除処理フローを示すフローチャートである。
【図１７】プログラム４０５の処理フローを示すフローチャートである。
【図１８】逆リソース表からのリソースの検索処理フローを示すフローチャートである。
【図１９】逆リソース表からの１検索情報の検索処理フローを示すフローチャートである。
【図２０】検索結果の検定処理フローを示すフローチャートである。
【図２１】実施例２における、Ｓ３１３〜Ｓ３２１、ステップＳ７１３〜Ｓ７２１、ステップＳ１０１３〜Ｓ１０２１の代わりの処理を示すフローチャートである。
【図２２】本発明の実施例４のシステムの基本構成を示す図である。
【図２３】プログラム４０２の処理フローを示すフローチャートである。
【図２４】プログラム４０３の処理フローを示すフローチャートである。
【図２５】プログラム４０５の処理フローを示すフローチャートである。
【図２６】プログラム４０７の処理フローを示すフローチャートである。
【図２７】プログラム４０５の処理フローを示すフローチャートである。
【図２８】逆リソース表からの検索処理フローを示すフローチャートである。
【符号の説明】
【００９３】
１０１  ユーザ端末
３０１  データベースサーバ
４０１  プログラム（受取手段）
４０２  プログラム（登録手段）
４０３  プログラム（削除手段）
４０４  プログラム（更新手段）
４０５  プログラム（検索手段）
４０６  外部プログラム（準候補キー検索手段）
【図１】
2006092509.tif 000003
【図２】
2006092509.tif 000004
【図３】
2006092509.tif 000005
【図４】
2006092509.tif 000006
【図５】
2006092509.tif 000007
【図６】
2006092509.tif 000008
【図７】
2006092509.tif 000009
【図８】
2006092509.tif 000010
【図９】
2006092509.tif 000011
【図１０】
2006092509.tif 000012
【図１１】
2006092509.tif 000013
【図１２】
2006092509.tif 000014
【図１３】
2006092509.tif 000015
【図１４】
2006092509.tif 000016
【図１５】
2006092509.tif 000017
【図１６】
2006092509.tif 000018
【図１７】
2006092509.tif 000019
【図１８】
2006092509.tif 000020
【図１９】
2006092509.tif 000021
【図２０】
2006092509.tif 000022
【図２１】
2006092509.tif 000023
【図２２】
2006092509.tif 000024
【図２３】
2006092509.tif 000025
【図２４】
2006092509.tif 000026
【図２５】
2006092509.tif 000027
【図２６】
2006092509.tif 000028
【図２７】
2006092509.tif 000029
【図２８】
2006092509.tif 000030