(57)【要約】【課題】  より効率的かつ柔軟性のある高度な照会機能または手法を提供するためのシステムおよび方法を提供すること。【解決手段】  従来のデータベーススキーマの方式においてデータソースのネットワークを提供し、従来のデータベース照会をネットワークメッセージに変換し、それらのメッセージを、いくつかの例においては指定された照会ノードを通じて、関連するデータを持つデータソースにルーティングする、方法およびシステム。本発明においては、これらのデータソースは、メッセージを受け取り、次いで、応答メッセージを照会の発信装置に送信し、またはいくつかの実施例においては指定されたジョインノードを介して送信する。いくつかの実施例においては、データソースは、ローカルジョイン操作を実行できる。次いで、システムは、これらの応答メッセージを、適切な場合に、指定されたジョインノード、指定された照会ノード、および／またはデータソースにおいて集め、照会の条件を満たす応答メッセージが、照会の発信装置に送り返される。照会の発信装置に提供された照会結果は、従来のデータベース結果として提示される。
2006503342.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が、少なくとも1つのテーブル名と、少なくとも1つのテーブル属性と、少なくとも1つのテーブル属性の値とを含む、ステップと、
当該照会を、テーブル名と、テーブル属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の中の当該テーブル名と、当該テーブル属性と、当該値の当該特定のセットに関連するデータソースに伝送するステップと、
当該照会が満たされるときに、当該照会の当該テーブル名と、当該テーブル属性と、当該値の当該特定のセットに関連する当該データソースから少なくとも1つの応答メッセージを受信するステップと、
当該少なくとも1つの応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップ、
を有する、方法。
【請求項２】
当該スキーマを提供するステップが、各テーブル属性のランクを提供するステップを含み、かつ、当該照会の中の当該テーブル属性の当該ランクの相対値が、当該伝送ステップにおいてルーティングキーとして使用されるテーブル、テーブル属性、および値を選択するために使用される、請求項1の方法。
【請求項３】
請求項1の方法であって、当該方法が、当該少なくとも1つの応答メッセージが受信された後、当該照会に含まれるジョインを解決するステップをさらに含む、方法。
【請求項４】
当該ネットワークメッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、またはCDMA形式パケットか、または当該パケットの複合である、請求項1の方法。
【請求項５】
当該照会言語が、SQLを有する、請求項1の方法。
【請求項６】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースに、特性ベースのルーティングを使用してルーティングするステップを有する、請求項1の方法。
【請求項７】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用してルーティングするステップを有する、請求項1の方法。
【請求項８】
各属性の当該ランクが、
ネットワークトポロジに沿って前記レコードを分割する属性が最高ランクとなり、かつ、多数の異なる値を有する属性が、少数の異なる値を有する属性よりもランクが高い、という指針
に基づいて選択される、請求項2の方法。
【請求項９】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が、少なくとも1つのクラス名と、少なくとも1つのクラス属性と、少なくとも1つのクラス属性の値とを含む、ステップと、
当該照会を、クラス名と、クラス属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の中の当該クラス名と、当該クラス属性と、当該値の当該特定のセットに関連するデータソースに伝送するステップと、
当該照会が満たされるときに、当該照会の当該クラス名と、当該クラス属性と、当該値の当該特定のセットに関連する当該データソースから少なくとも1つの応答メッセージを受信するステップと、
当該少なくとも1つの応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップ、
を有する、方法。
【請求項１０】
当該スキーマを提供するステップが、各クラス属性のランクを提供するステップを含み、かつ、当該照会の中の当該クラス属性の当該ランクの相対値が、当該伝送ステップにおいて前記ルーティングキーとして使用されるクラス、クラス属性、および値を選択するために使用される、請求項9の方法。
【請求項１１】
請求項9の方法であって、当該方法が、当該少なくとも1つの応答メッセージが受信された後、当該照会に含まれるジョインを解決するステップをさらに含む、方法。
【請求項１２】
当該ネットワークメッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、またはCDMA形式パケットか、または当該パケットの複合である、請求項9の方法。
【請求項１３】
当該照会言語が、SQLを有する、請求項9の方法。
【請求項１４】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースに、特性ベースのルーティングを使用してルーティングするステップを有する、請求項9の方法。
【請求項１５】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用してルーティングするステップを有する、請求項9の方法。
【請求項１６】
各属性の当該ランクが、
ネットワークトポロジに沿って前記レコードを分割する属性が最高ランクとなり、かつ、多数の異なる値を有する属性が、少数の異なる値を有する属性よりもランクが高い、という指針
に基づいて選択される、請求項10の方法。
【請求項１７】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が、少なくとも1つのタグ名と、少なくとも1つのタグ属性と、少なくとも1つのタグ属性の値とを含む、ステップと、
当該照会を、タグ名と、タグ属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の中の当該タグ名と、当該タグ属性と、当該値の当該特定のセットに関連するデータソースに伝送するステップと、
当該照会が満たされるときに、当該照会の当該タグ名と、当該タグ属性と、当該値の当該特定のセットに関連する当該データソースから少なくとも1つの応答メッセージを受信するステップと、
当該少なくとも1つの応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップ、
を有する、方法。
【請求項１８】
当該スキーマを提供するステップが、各タグ属性のランクを提供するステップを含み、かつ、当該照会の中の当該タグ属性の当該ランクの相対値が、当該伝送ステップにおいて前記ルーティングキーとして使用されるタグテーブル、タグ属性、および値を選択するために使用される、請求項17の方法。
【請求項１９】
請求項17の方法であって、当該方法が、当該少なくとも1つの応答メッセージが受信された後、当該照会に含まれるジョインを解決するステップをさらに含む、方法。
【請求項２０】
当該ネットワークメッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、もしくはCDMA形式パケット、または当該パケットの複合である、請求項17の方法。
【請求項２１】
当該照会言語が、SQLを有する、請求項17の方法。
【請求項２２】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースに、特性ベースのルーティングを使用してルーティングするステップを有する、請求項17の方法。
【請求項２３】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用してルーティングするステップを有する、請求項17の方法。
【請求項２４】
各属性の当該ランクが、
ネットワークトポロジに沿って前記レコードを分割する属性が最高ランクとなり、かつ、多数の異なる値を有する属性が、少数の異なる値を有する属性よりもランクが高い、という指針
に基づいて選択される、請求項18の方法。
【請求項２５】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードおよび複数のデータソースと、特定のデータソースを表す複数のアーカイブノードとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップと、
当該照会を少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会に関連するデータソースに伝送するステップと、
正常にアクセスされたデータソースのリストを当該ネットワークから受信するステップと、
当該ネットワークメッセージを当該アーカイブノードと当該リスト上のデータソースとに再伝送するステップと、
当該リストからの当該データソースからと、当該照会に合致するが当該リスト上にないデータソースを表す当該アーカイブノードとから、応答メッセージを受信するステップと、
当該応答メッセージに基づいて照会結果を当該データベース言語において提供するステップ、
を有する、方法。
【請求項２６】
当該ネットワークメッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、またはCDMA形式パケットか、または当該パケットの複合である、請求項25の方法。
【請求項２７】
当該スキーマが、リレーショナルスキーマ、オブジェクト指向スキーマ、またはオブジェクトリレーショナルスキーマを有する、請求項25の方法。
【請求項２８】
当該照会言語が、SQLを有する、請求項25の方法。
【請求項２９】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースに、特性ベースのルーティングを使用してルーティングするステップを有する、請求項25の方法。
【請求項３０】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用してルーティングするステップを有する、請求項25の方法。
【請求項３１】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップであって、当該スキーマが、ローカルにジョイン可能な記述子のリストを提供する、ステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が複数の述語を含む、ステップと、
当該照会を少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の当該複数の述語に関連するデータソースに伝送するステップと、
当該ローカルにジョイン可能な記述子のリストに含まれる当該照会の述語が当該データソースにおいてローカルにジョインされるときに、当該ネットワークメッセージへの応答メッセージを、当該照会に関連する当該データソースから受信するステップと、
当該応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップ、
を有する、方法。
【請求項３２】
ネットワークメッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、またはCDMA形式パケットか、または当該パケットの複合である、請求項31の方法。
【請求項３３】
当該スキーマが、リレーショナルスキーマを有し、かつ、当該記述子が、属性またはテーブルを有し、オブジェクト指向スキーマと当該記述子が、クラス属性、クラス、またはオブジェクトリレーショナルスキーマを有する、請求項31の方法。
【請求項３４】
当該照会言語が、SQLを有する、請求項31の方法。
【請求項３５】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースに、特性ベースのルーティングを使用してルーティングするステップを有する、請求項31の方法。
【請求項３６】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用してルーティングするステップを有する、請求項31の方法。
【請求項３７】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと少なくとも1つの指定された照会ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が複数の副照会を含む、ステップと、
当該照会を、複数のネットワークメッセージに分解するステップであって、当該複数のネットワークメッセージの1つが、当該複数の副照会に対応する、ステップと、
当該複数のネットワークメッセージの1つを、当該照会の当該複数の副照会の当該1つに関連する指定された照会ノードに伝送するステップであって、当該少なくとも1つの指定された照会ノードが、当該複数の副照会の当該1つを処理し、かつ、当該照会の断片を、当該照会の断片に関連しかつ当該少なくとも1つの指定された照会ノードが責任を持つ対象のデータソースに伝送する、ステップと、
当該照会の断片への応答がジョインされかつ当該照会が満たされるときに、当該少なくとも1つの指定された照会ノードから、当該ネットワークメッセージへの応答メッセージを受信するステップと、
当該応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップ、
を有する、方法。
【請求項３８】
当該スキーマが、ローカルにジョイン可能な記述子のリストを提供し、
当該スキーマが、リレーショナルスキーマであり、かつ、当該記述子が、属性またはテーブルを含む、
または、
当該スキーマが、オブジェクト指向スキーマであり、かつ、当該記述子が、クラス属性またはクラスを含む、
請求項37の方法。
【請求項３９】
当該少なくとも1つの指定された照会ノードが、当該分散型データソースネットワークデータベースの主要分岐ポイントに位置する、請求項37の方法。
【請求項４０】
当該スキーマを提供するステップが、各属性のランクを提供するステップを含み、かつ、当該照会が属性を含み、かつ、当該照会の中の当該属性の当該ランクの相対値が、当該伝送ステップにおけるルーティングキーを選択するために使用される、請求項38の方法。
【請求項４１】
当該ネットワークメッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、またはCDMA形式パケットか、または当該パケットの複合である、請求項37の方法。
【請求項４２】
各属性の当該ランクが、
ネットワークトポロジに沿って前記レコードを分割する属性が最高ランクとなり、かつ、多数の異なる値を有する属性が、少数の異なる値を有する属性よりもランクが高い、という指針
に基づいて選択される、請求項37の方法。
【請求項４３】
当該照会言語が、SQLを有する、請求項42の方法。
【請求項４４】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースに、特性ベースのルーティングを使用してルーティングするステップを有する、請求項37の方法。
【請求項４５】
当該伝送ステップが、当該ネットワークメッセージを、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用してルーティングするステップを有する、請求項37の方法。
【請求項４６】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
1つ以上の関数を少なくとも1つのノードに分散させるステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップと、
当該照会を少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会に関連するデータソースに伝送するステップと、
当該照会が満たされかつ当該1つ以上の関数が適用されるときに、当該ネットワークメッセージへの応答メッセージを、当該照会に関連する当該データソースから受信するステップと、
当該応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップ、
を有する、方法。
【請求項４７】
当該1つ以上の関数が、命令を有し、当該命令が、当該少なくとも1つのノードに分散されているオブジェクトクラスのメソッドを有し、当該少なくとも1つのノードが、オブジェクト指向データソースを有する、請求項46の方法。
【請求項４８】
当該1つ以上の関数が、命令を有し、当該命令が、データ低減命令の分散を有する、請求項46の方法。
【請求項４９】
当該1つ以上の関数が、命令を有し、当該命令が、平均計算、デルタ抽出、ピーク抽出、またはハッシュ化を有する、請求項46の方法。
【請求項５０】
当該1つ以上の関数が、命令を有し、当該命令が、データ圧縮命令の分散を有する、請求項46の方法。
【請求項５１】
当該1つ以上の関数が、命令を有し、当該命令が、関連する要約を抽出するトレンド分析命令の分散を有する、請求項46の方法。
【請求項５２】
当該少なくとも1つのノードが、データソースを有する、請求項46の方法。
【請求項５３】
当該少なくとも1つのノードが、指定されたジョインノードを有する、請求項46の方法。
【請求項５４】
請求項53の方法であって、当該方法が、当該指定されたジョインノードにおいて当該ネットワークメッセージを受信するステップと、当該指定されたジョインノードにおいて当該1つ以上の関数を実行するステップと、当該1つ以上の関数に従っての当該ネットワークメッセージからの当該照会の部分への応答を、当該照会に関連するデータソースから受信するステップ、をさらに有する、方法。
【請求項５５】
当該1つ以上の関数が、当該スキーマの新しい側面に関係する、請求項47の方法。
【請求項５６】
データソースのネットワークを有する分散型データベースの情報管理のためのシステムであって、当該システムが、
当該ネットワークに結合されている複数のデータソースであって、当該データソースが、当該分散型データベースのスキーマに従って情報を提供することのできる、データソースと、
当該ネットワークに結合されている少なくとも1つの照会側ノードであって、当該照会側ノードが、データベース言語での照会を受信し、かつ、当該照会を、当該照会に関連するデータソースに当該ネットワークを通じて伝送される少なくとも1つのネットワークメッセージに分解することができる、照会側ノードと、
を有するシステムにおいて、
当該照会に関連するデータソースが、当該照会が満たされるときに当該ネットワークメッセージに応答して応答メッセージを当該ネットワークを通じて送信し、かつ、当該照会側ノードが、当該応答メッセージからの照会結果を当該データベース言語において提供し、
当該照会が、
当該複数のデータソースが、当該照会に対するローカルジョインを実行することのできる少なくとも1つのデータソースを含む、
システム。
【請求項５７】
当該ネットワークメッセージと当該応答メッセージが、イーサネットパケット、IPパケット、TCPパケット、UDPパケット、Profibusパケット、DeviceNetパケット、IEEE 802.11パケット、Ricochetパケット、GSM形式パケット、またはCDMA形式パケットか、または当該パケットの複合である、請求項56のシステム。
【請求項５８】
当該スキーマが、リレーショナルスキーマ、オブジェクト指向スキーマ、またはオブジェクトリレーショナルスキーマを有する、請求項56のシステム。
【請求項５９】
当該照会言語が、SQLを有する、請求項56のシステム。
【請求項６０】
当該ネットワークメッセージが、当該照会に関連するデータソースにのみ、特性ベースのルーティングを使用して当該ネットワークを通じて伝送される、請求項56のシステム。
【請求項６１】
当該ネットワークメッセージが、当該照会に関連するデータソースにのみ、マルチキャストルーティングを使用して当該ネットワークを通じて伝送される、請求項56のシステム。
【請求項６２】
当該伝送ステップが、指定されたしきい値よりビットベクトル表現が小さいブルームフィルタのビットベクトルの伝送を有する、請求項31の方法。
【請求項６３】
当該少なくとも1つの指定された照会ノードが、当該分散型データソースネットワークデータベースの重心位置の近くに位置し、当該重心位置が、当該照会側ノードと当該照会に関連する当該データソースとの間の最適な位置を含む、請求項37の方法。
【請求項６４】
当該最適な位置が、当該照会側ノードと当該照会に関連する当該データソースとの間の等しい距離にあるポイントを含む、請求項63の方法。
【請求項６５】
当該最適な位置が、照会関連データの量がその両側において等しくなるポイントを含む、請求項63の方法。
【請求項６６】
当該分散ステップが、1つ以上の関数の本体と1つ以上の関数クロージャとを、当該少なくとも1つのノードに分散させるステップを含む、請求項46の方法。
【請求項６７】
当該少なくとも1つのノードが、照会側ノードを有する、請求項66の方法。
【請求項６８】
当該少なくとも1つのノードが、指定された照会ノードを有する、請求項66の方法。
【請求項６９】
当該分散ステップを、当該照会を通じて行うことができる、請求項46の方法。
【請求項７０】
請求項46の方法であって、当該方法が、照会メッセージの終了を当該照会に関連する当該データソースに送信するステップをさらに有する、方法。
【請求項７１】
当該命令が、関連する要約を抽出するトレンド分析命令の分散を有する、請求項46の方法。
【請求項７２】
当該少なくとも1つのノードが、データソースを有する、請求項46の方法。
【請求項７３】
当該少なくとも1つのノードが、指定された照会ノードを有する、請求項46の方法。
【請求項７４】
請求項54の方法であって、当該方法が、当該指定された照会ノードにおいて当該ネットワークメッセージを受信するステップと、当該指定された照会ノードにおいて当該命令を実行するステップと、当該照会に関連するデータソースから、当該命令に従っての当該ネットワークメッセージからの当該照会の部分への応答を、受信するステップと、をさらに有する、方法。
【請求項７５】
当該命令が、当該スキーマの新しい側面に関係する、請求項47の方法。
【請求項７６】
当該照会が、照会の制約および／または指定されたリフレッシュレートの形式における、および／または当該1つ以上の関数の中の前記宣言型ステップの一部としての、イベントまたは例外の記述を含み、かつ、当該1つ以上の関数が、当該イベントまたは当該例外が起きたときにとるべきアクションを有し、かつ、当該方法が、当該少なくとも1つのノードにおいて当該1つ以上の関数を実行してイベントベースのシステム反応を提供するステップをさらに有する、請求項46の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
関連出願
本出願は、共有出願の米国仮特許出願番号60／275,429（01P4385US）（出願日：2001年3月12日）について優先権を主張する。
【０００２】
さまざまの異なる条件下においてデータソースの分散型ネットワークデータベースシステムから特定の必要な情報にアクセスする能力が望まれる。しかしながら、従来のシステムにおいては、状況によっては、必要なデータへのアクセスおよび管理に困難が生じることがある。
【０００３】
例えば、データソースのネットワークに関して現在の技術における困難の1つは、データソースからの、特に、非常に大規模なデータソースからの、または非常に多数のデータソースからのデータを管理する方法である。データソースのネットワークにおいては、データ管理が難しく、なぜなら、大規模なデータソース、または場合によっては多数のデータソースによって送信されるデータが、使用されるネットワークまたはデータ管理システムにとって圧倒的な量となりうるためである。
【０００４】
また、ネットワーク内のデータソースから提供される情報が、頻繁に変更または更新されることもある。データが動的となりうるこのような状況においては、従来のシステムには、データソースのネットワークに任意の瞬間に追加（または削除）されるデータソースからのデータ入力についてを、照会結果に動的に反映させるためのメカニズムが用意されていないことがしばしばある。さらに、データの動的度が低く、より静的な状況においても、従来のシステムには、動的なデータと静的なデータの一方または両方が存在する状況を考慮するための柔軟性が備わっていないことがある。
【０００５】
ネットワークの帯域幅が狭いかまたは信頼性が低いとき（例えばネットワークを通じて送信する必要のある制御オーバーヘッドの量に起因する）、または一時的な誤動作またはその他の理由によってデータソースにアクセスできないときには、適切または正確なデータ管理を達成するうえでのさらなる困難が生じることがある。
従って、さまざまな環境下におけるデータソースネットワークの有用なデータ管理を目的とした、より効率的かつ柔軟性のある高度な照会機能または手法を提供するためのシステムおよび方法が望まれる。
【０００６】
【特許文献１】米国特許出願番号09/728,380  (出願日：2000年11月28日)
【発明の開示】
【課題を解決するための手段】
【０００７】
上述されている問題と欠点は、さまざまな実施例に従って本発明によって克服される。本発明は、従来の情報技術のデータ管理手法をデータソースのネットワーク内に直接的に適用することを可能にする。より具体的には、本発明は、ネットワーク化されたデータソースを論理的に接続するネットワークに論理的に接続されているデバイス上で動作するプログラムが、従来のデータベース照会をネットワーク上に発行し、ネットワーク化されたデータソースによって生成されるデータにその照会が適用されるときに、その照会の結果をネットワークから受信することを可能にする。
【０００８】
特定の実施例によると、本発明は、複数のノードを含む分散型データソースネットワークデータベースの情報管理のための方法を提供する。前記複数のノードは、照会側ノードと複数のデータソースとを含む。当該方法は、前記分散型データソースネットワークデータベース用のスキーマを提供するステップと、データベース言語での照会を前記ネットワーク内の前記照会側ノードに入力するステップとを含む。また、当該方法は、前記照会を、テーブル名と、テーブル属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、前記ネットワークメッセージを、前記照会の中の前記テーブル名と、テーブル属性と、値の前記特定のセットに関連するデータソースに伝送するステップと、前記照会が満たされるときに前記照会の前記テーブル名と、テーブル属性と、値の前記特定のセットに関連する前記データソースから少なくとも1つの応答メッセージを受信するステップと、前記少なくとも1つの応答メッセージからの照会結果を前記データベース言語において前記照会側ノードに提供するステップ、も含む。スキーマが例えばオブジェクト指向スキーマである別の類似する特定の実施例においては、上述されているテーブル名とテーブル属性は、クラス名とクラス属性に置き換わる。
【０００９】
別の特定の実施例によると、本発明は、複数のノードを含む分散型データソースネットワークデータベースの情報管理のための方法を提供する。前記複数のノードは、照会側ノードと複数のデータソースとを含む。当該方法は、前記分散型データソースネットワークデータベース用のスキーマを提供するステップと、データベース言語での照会を前記ネットワーク内の前記照会側ノードに入力するステップと、前記照会を少なくとも1つのネットワークメッセージに分解するステップとを含む。スキーマは、ローカルにジョイン可能な属性またはテーブルのリストを提供し、前記照会は、複数の述語を含む。また、当該方法は、前記ネットワークメッセージを、前記照会の前記複数の述語に関連するデータソースに伝送するステップと、前記ネットワークメッセージへの応答メッセージを、前記照会に関連する前記データソースから受信するステップであって、前記ローカルにジョイン可能な属性またはテーブルのリストに含まれる前記照会の述語が、前記データソースにおいてローカルにジョインされる、ステップと、前記応答メッセージからの照会結果を前記データベース言語において前記照会側ノードに提供するステップ、も含む。
【００１０】
別の特定の実施例によると、本発明は、複数のノードを含む分散型データソースネットワークデータベースの情報管理のための方法を提供する。前記複数のノードは、照会側ノードと、複数のデータソースと、特定のデータソースを表す複数のアーカイブノードとを含む。当該方法は、前記分散型データソースネットワークデータベース用のスキーマを提供するステップと、データベース言語での照会を前記ネットワーク内の前記照会側ノードに入力するステップと、前記照会を少なくとも1つのネットワークメッセージに分解するステップと、前記ネットワークメッセージを、前記照会に関連するデータソースに伝送するステップとを含む。また、この方法は、正常にアクセスされたデータソースのリストを前記ネットワークから受信するステップと、前記ネットワークメッセージを前記アーカイブノードと前記リスト上の前記データソースとに再伝送するステップと、前記リストからの前記データソースからと、前記照会に合致するが前記リスト上にないデータソースを表す前記アーカイブノードとから、応答メッセージを受信するステップと、前記応答メッセージに基づいて前記データベース言語での照会結果を提供するステップ、も含む。
【００１１】
本発明の上記およびその他のさまざまな特定の実施例と、本発明の特徴および利点は、添付されている図面を参照しながら、以下により詳細に説明される。
【発明を実施するための最良の形態】
【００１２】
I.  システム全般
A.  照会側ノードにおける照会からネットワークメッセージへの翻訳
B.  ネットワークを通じてのネットワークメッセージのルーティング
C.  ネットワークメッセージに対するネットワークインタフェースの応答
D.  照会側ノードにおける応答メッセージの処理と照会結果の生成
E.  照会のリフレッシュの終了
II.  データテーブルのジョイン
A.  ローカルジョイン
B.  非ローカルジョイン
C.  指定されたジョインノード
D.  指定された照会ノード
III.  宣言型機能をプッシュすることによるイベントベース能力の達成
A.  データ管理機能の分散
B.  データソースの機能のインストール
C.  照会のリフレッシュの終了
IV.  アクセスできないデータソースの扱い
V.  結論
【００１３】
I.  システム全般
特定の実施例によると、本発明は、従来のデータベーススキーマの方式でデータソースのネットワークを記述し、従来のデータベース照会をネットワークメッセージに変換し、それらのメッセージを、関連データを持つデータソースにルーティングする、システムを含む。本発明においては、データソースのネットワークインタフェースは、メッセージを受け取り、メッセージ内の命令に従ってデータソースの出力をフィルタリングするか、または、ネットワークメッセージ内の制約および／または命令に従って照会に関連する情報をデータソースから取り出し、次いで、関連情報と一緒に応答メッセージを照会の発信装置に送信する。次いで、システムは、照会の発信装置においてこれらの応答メッセージを集め、従来のデータベースとしての照会結果を生成する。本発明は、特定の実施例によると、処理パワーが制限されているデータソースをサポートすることにおいて新規性があるが、本発明は、他の特定の実施例によると、データソースがより大きな処理パワーを持つ用途にも適切であり、なぜならこのようなデータソースはこのシステムの他の利点を利用できるためである。
【００１４】
本発明は、データソースのネットワークが単一のデータベースであるかのように、データソースのネットワークが複数の分散されたクライアントによって管理されることを可能にする、システムおよび方法を提供する。より具体的には、本発明は、ネットワーク化されたデバイス上で動作するプログラムがそのネットワークインタフェースにデータベース照会を発行し、ネットワークのインフラストラクチャがこの照会の結果を計算してこれらの結果を照会側デバイスに戻すことを可能にする。本発明の特定の実施例は、多数の異なる用途における情報の管理に有用である。具体的な用途としては、工場設備の制御および管理などの産業オートメーションと、模範例を目的として後述されるようなロジスティクス管理における荷物の追跡があげられる。しかしながら、別の特定の実施例は、毒物の追跡または火災の追跡、幹線道路の交通管理、セキュリティ管理、スマートビルディングまたはスマートバトルフィールド（smart battlefield）用途、サプライチェーンの管理および実行、遠隔現場保守、公益事業の敷設網管理、運用データストア（operational data stores）、一般企業データ統合、その他の多数の用途に有用である。
【００１５】
後から詳しく説明されるが、本発明によって提供される利点のいくつかを挙げると、ユーザまたはプログラムが、構造化照会言語（SQL）など（ただしこれに限定されない）の周知の標準的な情報技術に従って、ネットワーク化されたデータソースからのデータにアクセスして処理することが可能になること、複数のユーザおよびプログラムが、ネットワーク内の任意のポイントからのデータソースデータにアクセスして処理することが可能になること、ポーリングシステムまたは継続的にリフレッシュが行われるシステムと比較してネットワークトラフィックが大幅に減少すること、データアクセスの失敗の中心点が生じないこと、データがデータソースから要求側ノードまでの直通経路を常に移動するため待ち時間が最小であること、照会側ノードが応答側データソースの物理的な位置を認識する必要がないこと、となる。
【００１６】
図1は、本発明を採用できるネットワークアーキテクチャの例を示す。当業者には、このアーキテクチャはインターネットワーク10、すなわちネットワークルータ15によって接続されるネットワークの集合であって、それぞれが互いに相互接続できるネットワークの集合として認識されるだろう。用語「ルータ」は、本文書においては一般的な意味で使用され、従来のルータ、ネットワークスイッチ、ゲートウェイ、ブリッジ、または個別のネットワークをブリッジングするコントローラを含む。本発明は、単一のネットワーク上でも使用できるが、インターネットワーク上においてより価値が高い。各ネットワークは、任意の数のノードを接続できる。このネットワークアーキテクチャ内のさまざまなノードとルータを接続しているライン35は、この特定の実施例においては有線接続である。本発明を採用できるもう1つのアーキテクチャは、無線ネットワークである。無線ネットワークは、図1に関して上述されているネットワークと違って、ノード間の直接的な接続が存在せず、データは、特定の伝送範囲を持つ近くのノードに無線技術によって伝達され、場合によっては「ラインオブサイト(line of sight)」制限がある。従って、これらの特定の実施例においては、無線インターネットワークの場合、ライン35は論理接続とみなすことができる。さらに、インターネットワークが無線ネットワークと有線ネットワークの組合せを含む実施例においては、ライン35は、それぞれ論理接続と有線接続である。この分野に精通する人には、帯域幅と電力消費をより効率的に利用するために伝送範囲と伝送速度を変えるための多数のアルゴリズムがあることが認識されるだろう。さらに、この分野に精通する人には、移動ノードまたは動的ノードを接続および再接続するために使用される多数のアルゴリズム（アドホックネットワーキングと呼ばれる）があることが認識されるだろう。このようなネットワークのアーキテクチャは固定されない。本発明は、このような方式と両立する。
【００１７】
本発明によると、ネットワーク上の各ノードはネットワークインタフェースを有し、照会はネットワーク内の任意のデータ消費装置ノードから発信できる。ネットワークノードは、データ生産装置20、データ消費装置25、またはこの両方（データ生産装置／消費装置30）である。データ生産装置（またはデータソース）20の例としては、センサー、ビジネスプロセスアプリケーション（ERP（Enterprise Resource Planning）システムなど）、データソースバンク(data source bank)（しばしば分散型I／Oと呼ばれる）、従来のデータベース（リレーショナルデータベースなど）、データウェアハウス（データマートまたはデータベースクラスタなど）があげられる。データ消費装置25の例としては、コントローラとモニタリングシステムがあげられる。データ生産装置／消費装置30であるノードの例としては、ユーザオペレータパネル、ユーザグラフィカルインタフェース、アプリケーションプログラムがあげられる。本発明の目的の場合、1つ以上のデータソースのネットワークとのインタフェースとして機能するコントローラは、単一のノードとみなされ、これはデータ生産装置／消費装置30の別の例である。ネットワーク内の任意のノードには、本発明による適切なソフトウェアをノードに埋め込むことによって、データ消費装置ノード、データ生産装置ノード、またはデータ生産装置／消費装置ノードの機能を設けることができる。しかしながら、本発明が動作するために、ネットワーク内のすべてのノードに本発明によるソフトウェアを設ける必要はない。
【００１８】
上述されているように、ネットワーク上の各ノード（各データソースを含む）は、そのノードが論理的に接続されているネットワーク上で使用されているネットワークプロトコルのタイプに適合するネットワークインタフェースを持つ。このネットワークインタフェースは、関連する従来のネットワークインタフェースプロトコルを含み、このプロトコルの例として、イーサネット、IP、TCP、UDP、Profibus、およびDeviceNetと、IEEE 802.11、Ricochet、GSM、CDMAなどの無線プロトコルとがあげられる（ただしこれらに限定されることはない）。これらのプロトコルによって、ネットワークインタフェースはネットワークからメッセージを受信できる。さらに、本発明は、データ消費装置のネットワークインタフェースと、データ生産装置の（例：データソースの）ネットワークインタフェースとに拡張を提供する。具体的には、各ノードのネットワークインタフェースには、一般的なネットワークプロトコルインタフェースに加えて、本発明の機能を提供するソフトウェアが含まれ、このソフトウェアについては後から詳しく説明されている。特定の実施例においては、この追加のソフトウェアは、望ましくは、ノード（例：データ消費装置ノード、データ生産装置ノード、データ生産装置／消費装置ノード）のネットワークインタフェースの中か、ノード（例：データ消費装置ノードまたはデータ生産装置／消費装置ノード）に常駐するアプリケーションの中か、またはノードに常駐する個別のソフトウェアプロセスの中に埋め込まれる（ROMなどのメモリに格納される）。データソースが分散されないことが望ましいときなどの別の特定の実施例においては、追加のソフトウェアは、ローカルエリアネットワークまたは直接的なポイントツーポイント接続によってデータソースに接続される個別のハードウェア上で動作できる。
【００１９】
本発明は、従来のデータベーススキーマの方式におけるデータソースのネットワークの記述を提供する。このデータベーススキーマを使用する場合、ネットワーク上のノードは、ネットワーク上のデータソース（例：データ生産装置20またはデータ生産装置／消費装置30）を「データベース」としてみなす。従来、リレーショナルデータベースにおいては、スキーマは、それぞれが列（各列は関係の属性に対応する）と行（各行はタプルと呼ばれる関係のグループ化に対応する）を持つテーブルを意味するものと理解されている。オブジェクト指向データベースにおいては、スキーマは、従来、オブジェクトクラスのセットを意味し、これは一般から特定への階層を形成できるものと理解されている。クラスは、クラス属性を含むものと理解されている。留意すべき点として、XMLデータベースは、本発明と相互作用する目的の場合には、オブジェクト指向データベースと同等である。XMLデータベースは、属性と値を含むデータクラス（タグタイプと呼ばれる）も持つ。スキーマを使用するリレーショナルとオブジェクト指向のいずれの考え方も、本発明の枠組みの中で使用できる。
【００２０】
データソースのネットワークをリレーショナルデータベースとしてみなすために、データソースの各タイプに対してスキーマ内にテーブルが作成される。このテーブルの属性は、(1)データソースが提供できる出力タイプそれぞれと、(2)データソースについての記述的情報の属性（例：データソースが接続されているコンポーネントのID、データソースが属すサブシステムのIDなど）と、(3) IDとを含む。この最後のIDは、テーブルにリストされる各データソースごとにテーブル内で一意である。いくつかのデータソースタイプが類似するがわずかに異なる場合には、これらのタイプを区別するための余分な属性を使用して、これらのデータソースタイプを1つのテーブルにマージしてもよい。
【００２１】
これに代えて、例えば大量のデータが中に格納されているデータソースの場合に望ましい方式においては、単一のデータソースが、いくつかのテーブルの一部を含むことができる。データソースのローカルスキーマがデータソースのネットワークのグローバルスキーマと異なる場合には、データソースのソフトウェアが、グローバルスキーマとローカルスキーマの間での照会の翻訳機能を提供してもよい。さらに、グローバルスキーマによって使用される正規化されたバージョンからデータソースのローカル方言バージョンに、およびこの逆に、データを翻訳する必要があることがある。例えば、データソースが配送トラック上のコンピュータである場合、このコンピュータが、トラックの目的地、状態、速度などを記述する属性を持つエントリをトラックテーブル内に含んでいることがあり、また、トラックが運んでいる各商品ごとに1つのエントリを含む商品テーブル内のエントリを含むこともある。
【００２２】
データソースのネットワークをオブジェクト指向データベースとしてみなすために、データソースの各タイプに対してオブジェクトクラスが定義される。これに代えて、例えば大量のデータが中に格納されているデータソースの場合に望ましい方式においては、単一のデータソースがいくつかのオブジェクトクラスを含むことができる。当業者には、いくつかのデータソースタイプが類似するがわずかに異なる場合には、これらのデータソースタイプを、より一般的な共通のクラスのサブクラスとして表すことができることが認識されるだろう。データソースのデータを検索できるようにするためのメソッドが、各クラス内に含まれる（例：データソースの各出力タイプごとに1つのメソッド）。また、データソースについての記述的情報（例：データソースが接続されているコンポーネントのID、データソースが属すサブシステムのIDなど）を検索するための追加のメソッドが含まれる。また、（例えばセンサーネットワーク用途において）ダイナミックレンジのリセット、較正、設定など、データソースの特殊な機能にアクセスするための追加のメソッドを含めることができる。
【００２３】
上述されているように、本発明は、スキーマを使用するデータソースのネットワークを、リレーショナルまたはオブジェクト指向のいずれかの考え方から見ることができる。本発明を明確に理解できるように、以下の説明では、特定の実施例による、リレーショナルデータベースの考え方からの本発明について説明する。オブジェクト指向の考え方（XMLデータベースを含む）からの本発明の他の特定の実施例も、本発明の範囲内であることが理解されるであろう。さらに、いくつかのデータベースは、リレーショナルの考え方とオブジェクト指向の考え方の組合せを使用するスキーマを持ち、これらのタイプのデータベースも本発明の範囲内である。
【００２４】
本発明の1つの観点は、データベーススキーマ全体をノードに明示的に格納する必要がないことである。各照会側ノードが知る必要があるのは、必要とするデータのテーブルと属性の名前のみであり、グローバルスキーマ全体を知る必要はない。データベースのスキーマは、後からさらに説明されるように、システムの挙動から暗黙的に決まる。しかしながら、データソースが従来のリレーショナルデータまたはオブジェクト指向データを含む場合、ローカルスキーマからグローバルスキーマへのマッピングを提供することは有用である。グローバルスキーマは変わることがあるため、このような場合におけるシステムのオプションの改良として、グローバルスキーマとマッピングを自動的に配置するためのメカニズムがあげられる。このための適切なメカニズムは、後のセクション「データ管理機能の分散」に説明されている。
【００２５】
スキーマが設計されると、本発明は、一般的には図2に従って動作する。これらの各ステップは、本文書の中の後からさらに詳細に説明されている。ステップ100において、ネットワーク内の消費装置ノード25または30は、従来のデータベース照会を発行できる。特定の実施例によると、照会は「リフレッシュレート」を指定でき、これは、その照会が存続することと、特定の頻度において現在のネットワークステータスに対して継続的に評価されることとを示す。ステップ102において、その照会が、照会側ノードのネットワークインタフェースによって、各データソースタイプに対する関連部分（ネットワークメッセージ）に分解される。次いで、ステップ104において、各ネットワークメッセージが、ルーティングシステムによってネットワークを通じて適切なタイプのデータソースにのみルーティングされる。場合によっては、ネットワークルータ15は、データソースのタイプに基づく以外に、照会からの制約に基づいてネットワークメッセージをルーティングする。ステップ106において、適切なデータソースのネットワークインタフェースによってネットワークメッセージが受信される。データソースのネットワークインタフェースは、必要な場合には照会をグローバルスキーマからローカルスキーマに変換する。各データソースのネットワークインタフェースは、フィードバックライン107によって示されているように、照会のリフレッシュレートに従って定期的に照会の制約をチェックする。制約が満たされていると、ステップ108において、データソースのネットワークインタフェースは照会に応答し、応答が元の照会側ノードにルーティングされる。ステップ110において、照会側ノードのネットワークインタフェースは、応答を集めて、照会が満たされているかについてこれらの応答を継続的にチェックする。照会が満たされているたびに、ステップ112において、ネットワークインタフェースは関連データを照会側プログラムまたはユーザに渡す。
【００２６】
A.  照会側ノードにおける照会からネットワークメッセージへの翻訳
上述されているように、本発明は、従来のデータベース照会を、データソースのネットワークに適切なネットワークメッセージに変換するためのシステムであって、各データソースが、1つ以上のデータベースレコード（リレーショナルモデル）またはオブジェクトインスタンス（オブジェクト指向モデル）、またはその組み合わせとしてみなされ、かつ、上述されているスキーマが使用される、システムを提供する。このシステムは、データソースに送信できるように各データソースに対する照会の関連部分を取り出す。具体的には、データ消費ノード25または30それぞれは、そのネットワークインタフェース内か、そのデータ消費ノード上に常駐するアプリケーションプログラム内のいずれかに、従来のデータベース照会を、適切なデータ生産ノード20または30に送信される照会の関連部分を含むネットワークメッセージに変換する必要なソフトウェア／ファームウェアを含む。このネットワークメッセージングソフトウェアは、照会の関連部分を取り出してから、これらの部分を、ネットワークを通じて伝送される代表的なネットワークプロトコルパケットのデータペイロード内（例：イーサネットパケットのペイロード内）にカプセル化されるメッセージに含める、機能を含む。
【００２７】
本発明は、さらに、特定の実施例によると、オプションの追加の仕様によって従来のデータベース照会を拡張する。照会は、照会が継続的であり特定の頻度で更新される必要があることを示す「リフレッシュレート」を指定できる。留意すべき点として、リフレッシュレートが指定された場合でも、後から詳しく説明されるように、照会には、照会の制約が満たされるときにのみ応答される。
【００２８】
特定の実施例によると、各データソースに対する照会の関連部分は、(1)制約のリスト（場合によっては空である）であって、データソースはこのリストに従って情報を送信するかを決定する必要のある、リストと、(2)制約が満たされているときにデータソースが戻す必要のある戻り値のリストと、(3)データソースが情報の送信を再考慮する必要のあるリフレッシュレート（オプション）と、(4)一意のメッセージIDと、(5)照会側ノードのアドレス、である。照会側ノードのアドレスは、基礎となるネットワークのサービスの一部として自動的に提供される場合には、省略できる。これらの部分は、照会に関与する各データソースのネットワークメッセージを形成する。ネットワークメッセージの正確な構造（例：上記の照会の関連部分を含むフィールドの順序および／またはサイズ）は、システムにおいて事前に決定される必要があるが、本発明にとって重大ではない。ネットワークメッセージは、1つのネットワークプロトコルパケットを使用して送信でき、またはネットワークメッセージを、複数のネットワークプロトコルパケットを使用して送信されるセグメントに分割することができる。
【００２９】
図3は、SQL照会を、上述されているネットワークメッセージに分解するための、特定の実施例によるシステムについて記述する。本発明は、照会言語としてSQLに限定されない。SQLは、リレーショナルデータベースの実質的に標準的な照会言語であり、オブジェクト指向データベースにおいても次第に使用されるようになりつつある。SQLは、現時点における主要なデータベース照会言語として、本発明の分解手法を適切に説明する役割を果たす。また、本文書において前述および強調されているように、本発明の特定の実施例による従来のデータベース照会をネットワークメッセージに分解するステップは、リレーショナルデータベース方式に照らして説明されているが、この方式に限定されないものとする。制約の述語の仕様は、ほとんどの照会言語の重要な部分であり、参照されているリレーショナルテーブル（オブジェクト指向の場合には参照されているクラス）に基づく述語の抽出は、このようなSQL以外の照会言語に場合にも、本発明に従って実行できる。ほとんどの他の照会言語の場合にも、OR式または副照会が可能であり、これらはSQLの場合について後述されているのと同じように扱われる。
【００３０】
図3に示されているように、本発明の特定の実施例によると、従来のデータベース照会を、照会側ノードによってネットワークを通じて送信されるネットワークメッセージに変換するためのシステムは、最初に、必要なメッセージを作成することから開始する。
【００３１】
ステップ150において、照会または副照会の式のWHERE句の中のOR式の各オペランド内で参照されている各テーブルに対して1つのメッセージが作成される。ステップ152において、OR式のオペランド内の、そのテーブルの列を参照する各述語が、メッセージ内に制約として含められる。（ステップ150の前に、照会と各副照会のWHERE句が積和標準形に変換されるが、この手順はこの分野において周知である。）次いで、ステップ154において、OR式の外側、かつ副照会式のWHERE句の中で参照されている各テーブルに対してメッセージが作成される。次いで、ステップ156において、副照会のWHERE句の中のそのテーブルの列の参照のうち、他のメッセージにはまだ含まれていない参照すべてが、新しいメッセージに制約として含められる。次いで、ステップ158において、OR式の外側かつ副照会式の外側のWHERE句の中で参照されている各テーブルに対して、メッセージが作成される。次いで、ステップ160において、このテーブルの列を参照するが他のメッセージにはまだ含まれていない述語すべてが、このメッセージに制約として含まれる。
【００３２】
ステップ162において、各メッセージ内の各制約について、その制約が1つのデータソースに「ローカル」な制約であるか、または多数のデータソースに「分散されている」制約であるかが識別される。これは、制約の中で参照されているテーブルの数をカウントすることによって達成される。カウントが1である場合には、制約は「ローカル」である。カウントが2またそれ以上である場合には、制約は「分散」である。
【００３３】
ステップ164において、システムは、各メッセージについて、メッセージが作成された対象のテーブルを参照するSELECT式の中の列すべてを集め、このリストに、そのテーブルを参照しかつメッセージの「分散」制約において現れる各列を追加する。このリストは、メッセージの「戻り値」としてメッセージに追加される。次いで、「分散」制約がメッセージの制約リストから削除される。
【００３４】
次いで、各メッセージについて、照会にリフレッシュレートが指定されている場合には、ステップ166において、メッセージにそのリフレッシュレートが含められる。次いで、ステップ168において、システムは、一意のメッセージIDとローカル照会側ノードのネットワークアドレスとをメッセージに含める。次いで、ステップ170において、システムは、各メッセージをネットワークを通じて送信する。
【００３５】
従って、（特定の要件を満たすコンテナの位置が選択されるように要求される工場オートメーション環境などの場合の）コンテナの位置をSELECTする形式における、単純かつ模範的な照会、
WHERE (predicate1)
（式中のpredicate1は例えば「Temp > 100 degrees（温度＞100度）」でよい）は、一意のメッセージIDと照会側ノードのネットワークアドレスとを持つ、predicate1を含むネットワークメッセージに翻訳されて送信される。また、次の形式における別の模範的な照会、
WHERE (predicate1 AND predicate2)
（式中のpredicate2は例えば「Pressure > 100 psi（「圧力＞100 psi）」でよい）は、predicate1を含むネットワークメッセージとpredicate2を含む別のネットワークメッセージに翻訳されて送信される。この場合、両方のネットワークメッセージは、同じメッセージIDと照会側ノードのネットワークアドレスとを持つ。さらに、次の形式における別の模範的な照会、
WHERE (predicate1 OR predicate3)
（式中のpredicate3は例えば「Volume < 250 cubic cm（体積＞250 cm3）」でよい）は、predicate1を含むネットワークメッセージとpredicate3を含む別のネットワークメッセージに翻訳されて送信される。この場合、両方のネットワークメッセージは、同じメッセージIDと照会側ノードのネットワークアドレスとを持つ。
他の特定の実施例によると、共通の副式を除去することに基づくさらなる最適化が可能であり、これはこの分野において周知である。
【００３６】
B.  ネットワークを通じてのネットワークメッセージのルーティング
照会がデータソースに関連するネットワークメッセージの集合に変換された後に、照会の履行を目的としてこれらのメッセージをデータソースに送信する必要がある。データソースアドレスの中央データベースを必要とすることなくこの送信を達成するためには、ネットワークルータは、メッセージの中で参照されているデータソースの記述（例：テーブル、クラス、属性、値）に基づいてメッセージをルーティングする方法を認識している必要がある。ネットワークメッセージが、発行された特定の照会に関連するデータソースのみにルーティングされるように、文字列ベースのメッセージのルーティング方法が必要である。
【００３７】
いくつかの実施例、特に、データ値が極めて動的である実施例においては、データのタイプ（テーブル名、クラス名、属性名など）が、関連するデータソースの記述子として使用される。他の実施例、特に、データ値の動的度が低い実施例においては、より細かくメッセージをルーティングし、これによってデータトラフィックを低減させることが望ましい。これは、特定の実施例によると、ルーティングキーとしてデータ値を（属性名とテーブル名またはクラス名などの関連付けられるタイプ情報と一緒に）選択することによって達成される。例えば、荷物配送用途においては、南カリフォルニアからカリフォルニア州バークリーに送られているはずの特定の荷物を照会するメッセージをすべてのTRUCK（テーブル（またはクラス）名）にルーティングする代わりに、メッセージをより明確に、TRUCKS.DESTINATION="Berkeley"にルーティングできる。多くの場合このようなトラックはトポロジ的に互いに近くに位置しているため、これによってネットワーク上の総トラフィックが大幅に減少する。
【００３８】
本発明の特定の実施例における文字列ベースのメッセージルーティングを実施するための望ましい手法は、共願の米国特許出願番号09／728,380、発明の名称「Characteristic Routing（特性ベースのルーティング）」（出願日：2000年11月28日）と、共願の米国特許出願番号___________、発明の名称「Characteristic Routing（特性ベースのルーティング）」（本出願と同時に出願）に詳細に説明されている特性ベースのルーティングであり、両方の出願は本文書に参考文献として組み込まれている。特性ベースのルーティングは、「特性」（特性とは複数の任意の記述的な識別名の形式におけるノードの記述である）の任意の混合を使用して、データをネットワークを通じて送信装置ノードから一連のノードにマルチホップ(multi-hop)式に転送することを可能にするルーティングプロトコルである。ノードは、複数の動的な特性を持つことができる。複数の特性を使用するルーティングを高速かつ効率的にするために、特性ベースのルーティングは、ビットベクトルと圧縮手法を使用してルーティングテーブルインデックスを作成することによって最適化される。照会される側のネットワーク化オブジェクト（例：データソース）のインデックスとして特性ベースのルーティングを使用することによって、データソースデータベースの分散型ネットワークから情報を高速かつ効率的に検索するための効率的なインデクシング(indexing)手段が提供される。具体的には、特性ベースのルーティングにより、照会に関連するデータソースを照会するために、データソースに個別にアクセスする必要性と、事前定義されるマルチキャストグループを作成する必要性がなくなる。特性ベースのルーティングにおいては、各ノードの特定の特性を表すビットベクトルが形成され、この場合、ビットベクトル内の各ビット位置はノードの一連の総特性のうちの特定の特性の存在を表す。特性ベースのルーティングを使用して送信されるネットワークメッセージは、照会の中で要求されている情報を持つデータソースに届けることができる。
【００３９】
代替の手法は、効率は低いが、メッセージルーティング用にインターネットプロトコルマルチキャスト（IPマルチキャスト）を使用し、各データソースに記述子を割り当てて特定のマルチキャストグループを形成することである。IPマルチキャストルーティングと比較したときの特性ベースのルーティングの利点は、上記に記されている特許出願に詳細に説明されている。
【００４０】
ネットワーク内のルータ15には、特定の実施例において利用できる、特定の記述子ベースのメッセージルーティングを実行するために必要な機能が設けられる。従って、ネットワークメッセージは、照会に関連する定義済み記述子を満たすデータ生産装置20または30にのみルーティングされる。
【００４１】
C.  ネットワークメッセージに対するネットワークインタフェースの応答
本発明は、図4に関して以下に説明されるように、データソースがネットワークメッセージに適切に応答できるように、各データソースのネットワークインタフェースの機能も拡張する。具体的には、各データ生産ノード20または30は、そのネットワークインタフェース内か、そのノード上に常駐するアプリケーションプログラム内のいずれかに、照会の制約が満たされているときに、受信されたネットワークメッセージを処理して適切な照会側ノードに応答メッセージを伝送する必要なソフトウェア／ファームウェアを含む。応答メッセージは、データ生産ノード20または30によってネットワークを通じて伝送される代表的なネットワークプロトコルパケットのデータペイロード内（例：イーサネットパケットのペイロード内）にカプセル化される。図4において分かるように、ステップ200において、上述されている形式のメッセージが、照会に関連する定義済みタイプを満たすデータソースによって受信されると、そのデータソースのネットワークインタフェースは、（例えばバッファ内の）未処理照会のリストにそのメッセージを追加する。
【００４２】
グローバルスキーマとローカルスキーマとが異なる特定の実施例においては、各メッセージ内の各制約は、ローカルスキーマに変換される。このステップの望ましい実施例は、XMLドキュメントとして利用可能なローカルスキーマとグローバルスキーマを保持し、これらのスキーマ間のマッピングをXLSTドキュメントとして保持することである。この分野に精通する人には、XSLTドキュメントがXMLドキュメント間のマッピングを定義することが認識されるだろう。
【００４３】
ステップ202において、未処理照会のリスト内の各ネットワークメッセージについて、データソースのネットワークインタフェースは、メッセージ内の各制約を「静的」または「動的」のいずれかとして特徴付ける。この特徴付けは、制約の中の列参照すべてを考慮することによって達成される。各データソースは、属性の値が変化する頻度に基づいて、どの属性が「静的」でありどの属性が「動的」であるとみなされるかのリストを維持する。ネットワークインタフェースは、ステップ204において、前のステップで特徴付けた制約がそのメッセージ内の最後の制約であるか否かを判断する。最後の制約でない場合には、システムはステップ202に戻り、メッセージ内の次の制約を特徴付ける。
【００４４】
メッセージ内の最後の制約が特徴付けられると、ステップ206において、データソースのネットワークインタフェースは、メッセージ内の制約すべてが「静的」であるか否かを判断する。メッセージ内の制約すべてが「静的」であると判断される場合には、ステップ208において、ネットワークインタフェースは、データソースの現在の指示値(reading)を照会の制約と一度比較する。ステップ210において、現在のデータ値が照会の制約を満たすと判断される場合には、ネットワークインタフェースは、応答メッセージを照会側ノードに発行する。この応答メッセージは、処理されたネットワークメッセージに指定されている戻り値の現在の値と、その制約が「静的」であったことの指示と、処理されたネットワークメッセージの一意のメッセージIDとを含む。応答側ノードのアドレスを含み、照会側ノードにアドレッシングされているこの応答メッセージは、元の照会側ノードにルーティングされるように、データソースのネットワークインタフェースによってネットワークを通じて伝送される。
【００４５】
ステップ206において、すべての制約が「静的」ではなく少なくとも1つの「動的な」制約が含まれると判断される場合には、ステップ214において、システムは、ネットワークメッセージ内にリフレッシュレートが指定されていたか否かを判断する。リフレッシュレートが指定されていない場合には、ネットワークインタフェースはステップ208に進み、データソースの現在の指示値を照会の制約と一度比較する。次いで、システムは、残りのステップ210と212を、上記にすでに説明されている方法と同じように実行する。
【００４６】
ステップ206と214において、それぞれ、メッセージに少なくとも1つの「動的な」制約が含まれ、かつネットワークメッセージにリフレッシュレートが指定されていたと判断される場合には、ステップ216において、ネットワークインタフェースは、現在のデータソースの指示値を照会の制約と比較する。ステップ218において、制約が満たされていないと判断される場合には、ネットワークインタフェースは、（ライン220によって示されるように）指定されるリフレッシュレートでステップ216に戻り、現在のデータソースの指示値を照会の制約と比較する。ステップ218において、制約が満たされていると判断される場合には、ステップ222において、ネットワークインタフェースは、応答メッセージを照会側ノードに発行する。この応答メッセージは、処理されたネットワークメッセージに指定されている戻り値の現在の値と、処理されたネットワークメッセージの一意のメッセージIDとを含む。照会側ノードにアドレッシングされているこの応答メッセージは、元の照会側ノードにルーティングされるように、データソースのネットワークインタフェースによってネットワークを通じて伝送される。ステップ224において、ネットワークメッセージ内にオプションとして指定できる所定の寿命パラメータの値を過ぎていると判断される場合には、ネットワークインタフェースはメッセージの処理を終了する。しかしながら、ステップ224においてこの値を過ぎていないと判断される場合には、ネットワークインタフェースはステップ216に戻り、指定されたリフレッシュレートにおいてもう一度比較を行う。次いで、上記にすでに説明されているように、システムはステップ216から続行する。
【００４７】
D.  照会側ノードにおける応答メッセージの処理と照会結果の生成
図5A〜5Cは、照会側ノードにおいて応答メッセージを集めて照会結果を生成するための機能を説明する。このシステムは、照会側ノード上に常駐するクライアントアプリケーション内で動作するソフトウェアか、照会側ノードのネットワークインタフェースのメモリに埋め込まれるソフトウェアでよい。このシステムは、3つの論理スレッドを持ち、これらは実際の個別のスレッドとして、または単一のモノリシックプロセスとして実施してよい。
図5Aにおいて分かるように、第一スレッドは、ネットワークからの応答メッセージを集めることに責任を持つ。具体的には、ステップ300において、各応答メッセージがネットワークから受信される。次いで、ステップ302において、各応答メッセージが適切なバッファに格納される。照会側ノードによって送信される元の（それぞれ自身のメッセージIDを持つ）各ネットワークメッセージごとに、異なるメッセージIDによってインデックス化される個別のバッファが維持される。応答メッセージに格納されているメッセージIDに基づいて、関連するバッファに応答が追加される。応答メッセージには、それが受信された時間を示すためにタイムスタンプが追加される。留意すべき点として、同じノードから複数の照会が発信されることがあり、その場合にこのスレッドはそのノードからの異なる照会に関連する応答メッセージを受け取る。
【００４８】
図5Bに示されている第二スレッドの目的は、システムのタイミング制約を実施することである。このスレッドは、ReplyLifetimeと呼ばれるタイミング間隔を含み、応答メッセージはこの間隔後にバッファから削除される。ReplyLifetimeの値は、ケースバイケースで決定されるが、適度なデフォルト値は、関連する照会のリフレッシュレートの例えば3倍である。このスレッドは、ReplyLifetimeより過去に受信された応答メッセージがないか、バッファすべてを継続的にチェックする。このようなメッセージが見つかると、そのメッセージは「静的」とマークされていない限りバッファから削除され、「静的」とマークされている場合にはそのままにされる。具体的には、ステップ330において、各バッファについて、各応答メッセージがスキャンされる。ステップ332において、応答メッセージが「静的」とマークされているか否かの判断が行われる。応答メッセージが「静的」でない場合には、ステップ330において、システムは次の応答メッセージのスキャンを続ける。応答メッセージが「静的」とマークされている場合には、ステップ334において、メッセージのタイムスタンプがReplyLifetime値より古いか否かの判断が行われる。古くない場合には、ステップ330において、システムはバッファ内の次の応答メッセージのスキャンを続ける。しかしながら、メッセージのタイムスタンプがReplyLifetime値より古い場合には、その応答メッセージがそのバッファから削除される。従って、「静的」とマークされ、かつ必要なしきい値を超える所定の時間より古い応答メッセージが削除される。
【００４９】
第三スレッドは、図5Cに示されているように、この照会側ノードから発行された照会すべてを継続的に評価する。このスレッドは、各バッファ内の応答メッセージを使用して、複数のデータソースからのデータに関与する照会の制約が満たされているかについてチェックする。データベースの専門用語においては、これらの述語は「ジョイン」と呼ばれる。例えば、照会に「A.PartID = B.PartID」（AとBはデータソースタイプ）などの述語が含まれる場合、この条件は、この制約を含むネットワークメッセージに対する応答メッセージが受信されたときにこのスレッドによって評価される。これの代替は、後のセクションにおいて説明されるように、ジョインを「展開する」ことである。特定の照会を完全に満たす一連の応答メッセージがバッファ内に存在するときには、照会のSELECT句に対応する値が、その照会を発行したプログラムまたはユーザに戻される。この戻される値が照会結果である。
【００５０】
E.  照会のリフレッシュの終了
特定の実施例によると、リフレッシュノードが指定された照会は、終了されるまで継続する。ノードは、照会の中で参照されるデータソースタイプを満たす各データソースに特殊な「terminate_query」メッセージを送信することによって、その照会を終了させることができる。この終了メッセージは、終了させるネットワークメッセージのメッセージIDを含む。その場合、データソースのネットワークインタフェースは、未処理照会のリストからそのネットワークメッセージを削除する。前述されているようにオプションとして、各データソースのネットワークインタフェースがネットワークメッセージをその寿命の経過後に自動的に削除できるように、照会に寿命を割り当てることができる。
【００５１】
照会が終了した時点において、照会側ノードは、バッファ内にまだ存在している、その照会に関連する応答メッセージも消去する。消去される応答メッセージには、「静的」とマークされている応答メッセージも含まれる。
【００５２】
II.  データテーブルのジョイン
データベース照会がグローバルスキーマ内の複数のテーブルにまたがるときには、それらのテーブルからのデータを一連の共通のキー値と共に1つに「ジョイン」することによって、照会の制約をその組み合わせられたテーブルに適用できるようにすることが望ましい。いくつかの特定の実施例においては、データが分散状態にあるために、ジョインされるテーブルからのデータを、ジョインされる前に複数のデータソースから中央ポイントに集める必要がある。この中央ポイントは、ジョインのためにデータを転送するのに必要なネットワークトラフィックの量を低減するため、情報ソースにできるだけ近い必要がある。ジョインされるデータテーブルが常にデータソース上に存在する特定の場合には、データソース自身においてジョインを行うことができる。
【００５３】
A.  ローカルジョイン
いくつかの特定の実施例によると、例えばデータソースが大量のデータを格納できる場合、単一のデータソースにいくつかのテーブルが存在することがある（例：データソースとしての配送トラックがトラックテーブルと商品テーブルのエントリを含む）ため、特定のジョイン操作を「ローカルにジョイン可能」と指定できるならばデータトラフィックを低減できる。「ローカルにジョイン可能」とは、データが伝送される前にデータソースにおいてジョインを行うことができるという意味である。一般には、データがいくつかのソースから提供される場合、それらのソースにおいてはジョインが実行されないことが望ましく、なぜなら、本来なら他のソースからのレコードと正しくジョインされていたはずのレコードがフィルタリングによって除外される可能性があるためである。しかしながら、特定のスキーマのセマンティクスが、情報が失われる危惧なしに特定のジョインをソースにおいて実行できることを指定することができる。
【００５４】
図6は、郵便ロジスティクス(postal logistics)用途に使用できる簡略化されたデータスキーマを示す。典型的な郵便ロジスティクス用途においては、50,000のオーダーのデータソース（例：トラック、飛行機、ステーションなどの三次コンテナ(tertiary container)）があり、データソースはいつでも自発的にシステムに追加またはシステムから削除される。このような用途においては、特定の荷物についての電子情報が、RF-IDタギング(RF-ID tagging)またはその他の公知の手法を使用するなどして、その荷物と一緒に移動する。本発明を使用すると、例えば大規模なクーリエサービスは、ハブ、サブステーション、トラック、および飛行機の流通／ステージング(staging)システムを、荷物の単一の「生きた」ネットワーク化データベースとして扱うことができ、このネットワーク内の任意のポイントの認証されたクライアントは、このデータベースに対する照会を発行し、その照会に応答して現在の回答を受信できる。各テーブルは分散され、データとその物理的な発現(manifestation)を格納する。この例において、VehicleレコードとStationレコードは、車両またはステーションの位置に格納される。Packageレコードは、荷物の場所、すなわち車両またはステーションのいずれかに格納される。Customerレコードは、荷物に関連付けられ、荷物と一緒に格納される。ConveyedByテーブルとStoredAtテーブルは、対応する車両またはステーションと一緒に格納される。
【００５５】
図6のスキーマ例においては、VehicleテーブルとConveyedByテーブルは、一対のローカルにジョイン可能なテーブルの例である。システムのセマンティクスは、特定のVehicle.VIDに対応するConveyedByテーブルのレコードすべてが、そのVehicle.VIDのVehicleレコードと同じデータソース（車両）に位置することを命令する。これらの2つのテーブルに対してジョインが要求される場合には、他とジョイン可能であるかもしれないレコードが失われる危惧なしに、車両データソースにおいてジョインをローカルに実行できる。
【００５６】
いくつかの実施例によると、一対のテーブルの属性すべてがローカルにジョイン可能でなくても、そのうちの特定の属性がローカルにジョイン可能である状況がありうる。例えば、図6の郵便スキーマにおいては、Package.ReceiverIDはCustomer.CIDとローカルにジョイン可能であり、なぜなら荷物の受け取り人を記述するCustomerレコードは各荷物と一緒に移動するためである。しかしながら、Package.DestZIPはCustomer.ZIPとローカルにジョイン可能ではない。これを説明するため、いま、荷物の行き先の郵便番号（ZIP）の地域に住む顧客すべての名前を見つけようとする照会を考える。この照会においては、一般にはZIP属性に対するジョインが生じる。この郵便番号の地域に住む顧客は多数存在し、これらの顧客すべてが特定のトラック内に記録されているわけではない。従って、ZIP属性に対するジョインをローカルに実行できず、実行すると、潜在的な多数の一致が見落とされる。
【００５７】
ローカルジョインに基づいて照会を最適化できるようにするため、特定の実施例によると、ローカルジョイン関係を含むようにスキーマの仕様が拡張される。すべてのジョインは、この拡張の使用によって識別されない限りはローカルにジョイン可能でないものと想定される。次の構文により、完全なテーブルの対、またはテーブル属性の特定の対のいずれかをローカルにジョイン可能と指定することができる。
join_locally_statement-> join_locally table, table
| join_locally table.attribute, table.attribute;
従って、照会の中の1つ以上の操作がデータソースにおけるローカルジョインとして処理可能である場合には、そのデータソースからネットワークを通じて照会側ノードに送り返されるデータの量を最小化できる。
【００５８】
B.  非ローカルジョイン
非ローカルジョインとは、データソースにおいてローカルに解決できないジョインである。非ローカルジョインの場合、ジョインされるレコードは複数のデータソースから来る。
いくつかの特定の実施例においては、データソースが大量のデータを持つ場合などにおいては、システムは、照会結果の予測されるサイズの昇順にジョインを展開する。照会側ノードにおいてすべてのデータを集めてからデータをジョインする代わりに、これらの特定の実施例においては、システムは、ジョインを展開する、すなわち1つのテーブルからのレコードを集めてこのレコードを使用して他のテーブルから戻されるデータをフィルタリングすることを選択できる。この方式は、第一ステップにおいて選択も行い、これにより、伝送されるレコード数が減少する。留意すべき点として、このように伝送されるレコード数が減少することは、データソースを論理的に接続するネットワークの帯域幅が制限されるとき、またはネットワークの信頼性が低い傾向にあるときに、特に有用となりうる。
【００５９】
図7は、特定の実施例による、非ローカルジョインを含む照会と、生成された述語グループの例を示す。留意すべき点として、ジョイン述語（V.Dest = S.Name）は両方のグループに現れ、なぜならこの述語は両方のテーブルに関与するためである。この照会が解決されるとき、ジョインは次のように展開される。すなわち、メッセージ1が送信されるときに、このジョイン述語が削除され、S.Nameが戻り値として要求される。S.Nameデータが集められ、メッセージ2に含められる。データソースは、含められている戻り値データに指定されたジョイン述語を満たすデータを持つ場合にのみ、メッセージ2に応答する。この方式でジョインを展開することは、応答時の非常に粗いフィルタとしての役割を果たし、この照会の結果として生成されるネットワークトラフィックを大幅に減少させる。図8は、メッセージ2のテキストの例を示し、%1は、図7の例に従ってリストされるデータに置き換わるプレースフォルダを示す。データソースは、4つの述語の論理ORなど、これをローカルに解釈する。
【００６０】
代替の実施例においては、S.Name値を表すために、ビットベクトルによって表されるブルームフィルタ(bloom filter)がメッセージ2の中で使用される。ブルームフィルタを使用することで、S.Nameの値を符号化するのに必要なメッセージオーバーヘッドの量を低減できる。S.Name値のリストの2進符号化のサイズが、指定されるしきい値を超えるときには、指定されるしきい値よりビットベクトル表現が小さいブルームフィルタが使用される。このような実施例においては、S.Nameの値を1つ以上のハッシュ関数を使用してビットベクトルにハッシュ化できる。S.Name値のハッシュ化のたびに、ハッシュ関数によって指定される位置のビットベクトル内のビットが1にセットされる。このメッセージ2が送信されるとき、このメッセージの本体は、V.Destの値の要求を含む以外に、ブルームフィルタのビットベクトルと、ビットベクトルの長さと、値を符号化するのに使用されたハッシュの数も含む。データソースがメッセージ2を受信すると、そのデータソースは照会の制約に合致する行すべてを取り出す。次いで、データソースは、V.Destの応答値すべてをメッセージ内のブルームフィルタと比較する。この比較は、同じハッシュ関数かつ同じ数のハッシュ関数を使用してV.Destをハッシュ化し、生成されたビット位置をブルームフィルタのビットベクトルと比較することによって行われる。V.Dest値に対して生成されたビット位置すべての値が1である場合には、そのV.Destに関係する行が応答メッセージに含められる。それ以外の場合には、その行は除外される。留意すべき点として、これはデータ値の確率的な比較形式であるため、ブルームフィルタを使用する結果として、S.Name値が列挙されていた場合よりも戻される行数が一般に少なくなるが、これは照会メッセージのサイズの節約を目的として行われる。
【００６１】
特定の実施例によると、述語グループが決定された後、さらに、それらがメッセージとして送信されるときの順序が決定される。適切な順序を選ぶことは、照会によって生成されるネットワークトラフィックに大きな影響を与えうる。いま、図7に示されている照会と述語グループを考える。前述されているように、非ローカルジョインが展開され、ジョイン述語が両方のグループにリストされる。グループ2が最初に発行される場合は、それぞれの目的地から60分以内にある世界中の車両すべてが応答し、これによりおそらくは大量の（かつほとんどが不要な）ネットワークトラフィックが生成される。グループ1が最初に発行される場合は、カリフォルニアのステーションのみが応答する（実際に、カリフォルニアのステーションのみがこの照会を受信する）。この最初のメッセージから検索されるS.Namesを使用すると、ジョイン述語を第二メッセージ用のフィルタとして使用でき、ずっと少ない数の車両が応答する。
【００６２】
望ましい特定の実施例においては、照会を処理するプロセッサがメッセージの好ましい順序付けを選択し、（セクション「ネットワークを通じてのネットワークメッセージのルーティング」の中で特定の実施例について前述されているように）適切なルーティングキーも選択する目的で、各テーブル属性の「ランク」が含まれるようにスキーマ定義の仕様が拡張される。データベースの設計者は、以下の指針に基づいて、スキーマのセマンティクスに基づいて各属性のランクを選択できる。すなわち指針とは、ネットワークのトポロジに沿ってレコードを分割する属性が最高ランクとなり、多数の異なる値を持つ属性は、少数の異なる値を持つ属性よりランクが高い、というものである。これらの指針が与えられると、ランク付けの選定はかなり単純になる。先のスキーマ例においては、属性Station.StateとVehicle.Destが高ランクとなり、属性Package.SpecHandlingとVehicle.Statusが低ランクとなる。
【００６３】
句の中の述語グループを順序付けるために、ランクが最高の非ジョイン述語が選択され、最初に発行されるグループとしてそのグループが選択される。次いで、ジョインが展開され、残りのグループの順序が決定される。同じ句の中の2つの述語グループがジョイン展開される場合（SQLにおいてはクロス乗積を示す）には、これらのグループを平行して解決できる。IN述語（副照会を示す）は、ランク付けを目的とする場合には非ジョイン述語として扱われる。
【００６４】
この特定の実施例によると、述語グループはメッセージに変換され、照会分解器によって決定される順序で発行される。副照会、OR句、および／またはクロス乗積が存在することにより、大量の処理を平行して行うことができる。前述されているように、応答の数をフィルタリングするため、非ローカルジョインが解決され、中間結果が後のメッセージと一緒に発行される。IN述語を含む述語グループは、その副照会が解決されるのを待ってから発行される。ジョインの最初の部分、またはクロス乗積の1つの部分によって結果が生成されない場合には、句の中の他のメッセージは送信されず、この句からの結果はない。副照会が結果を戻さない場合には、そのIN述語を含む句は解決されず、その句からの結果はない。
【００６５】
C.  指定されたジョインノード
上述されている実施例は、主として、照会側ノードまたはデータソースにおける、さまざまな応答メッセージ内で送信される戻された情報の処理（ジョイン処理を含む）について論じている。しかしながら、他の特定の実施例においては、戻された情報の処理は、漸進的ジョイン(progressive joins)によってネットワークを通じて情報が戻されるときに実行することができ、または、ジョインを実行するタスクを特定のノードに委託できる（「指定されたジョインノード」または「指定されたジョイン装置」と呼ばれる）。このノードは、照会される側のデータ生産ノードから照会側ノードまでのアップストリーム経路沿いに存在し、かつデータ生産ノードより大きな計算能力またはメモリを保持するノードである。どちらの場合にも、行われる処理は受動的である。言い換えれば、指定されるジョイン装置は、情報を処理目的で能動的に集めようとすることはない。代わりに、指定されたジョイン装置ノードは、情報のストリームが自身を通過するときにのみ、このストリームに対して処理を行う。
【００６６】
指定されたジョインノードは、応答メッセージが自身に到着したときに、その応答メッセージ内の戻り情報に対して計算を分散方式に実行する。指定されたジョインノードは、ジョインの実行に加えて、平均計算などを実行できる。指定されたジョインノードが使用される特定の実施例においては、ルーティングシステムによって適切なタイプのデータソースにネットワークメッセージがルーティングされるとき（図2におけるステップ104）に、そのような関連データソースに関連付けられている指定されたジョインノードが処理に参加する。漸進的ジョインまたは指定されたジョイン装置を使用する実施例の場合、照会側ノードにおける応答メッセージの処理が軽減または簡略化され、なぜなら、処理の多くはすでに行われていて、照会側ノードに送信される戻される情報はすでに処理済みであるためである。指定されたジョインノードは、低コスト、低機能のデータソース（すなわちデータ生産ノード）と高コスト、高機能の能動型コンポーネント（例：より高い処理パワーおよび／またはより多くのメモリを持つデータ生産／消費ノード、データ生産ノード、またはルータ）の混合をシステムが使用するときに特に有用である。このようなデバイスの混合は、例えば、データソースの既存のネットワークをアップグレードするとき、または全体的なシステムコストの節約が必要なときに起こることがある。
【００６７】
D.  指定された照会ノード
ジョイン情報が照会のルーティングツリー沿いのアップストリームを流れるときに、この情報を単純には処理またはジョインできないことがしばしばある。これは、ルーティングツリーの同じサブツリーの一部ではない複数の場所からの情報がジョインに必要なためである。従って、ジョイン処理の大部分は、ツリーのルートにあたる照会の送信装置のノードにおいて起こることになる。また、データソースが大量のデータを含むとき、またはソースの数が多数であるときにも、照会側ノードに向かうアップストリーム経路全体にジョイン操作を適用すると、ルータのスループットと、従ってシステム全体の効率が大幅に低下することがある。このような状況において、1つの望ましい方式は、副照会全体がデータソースにより近くにプッシュ(push)されるように、より高度な照会プランニングが行われるようにすることである。副照会がプッシュされる先のノードは、その副照会の「指定された照会ノード」となり、関連データソースすべてから情報を集め、ジョインを実行し、その結果を送信装置にのみ送り返すことによって、その副照会を能動的に処理する。さらに、指定された照会ノード自身は、副照会のより小さい部分とそれに対応するジョインを処理するための別のノードを再帰的に指定できる。
【００６８】
全体的なネットワークトラフィックを減少させるため、副照会はできるだけデータソース近くにプッシュする必要がある。データは相互に関連する必要があるため、このプッシュの際には、データへの副照会の移動と、副照会へのデータの移動の間でトレードオフが生じる。関連情報は基礎となるルーティングシステムから利用可能である。関連情報を使用するかまたはルーティングシステムを「閲覧」することにより、関連する受信装置またはデータソースと、送信装置（照会側ノード）からこれらの受信装置までのルーティングツリーの存在が明らかになる。このことは、データ量の少ないソースが多数ある場合に特に重要である。
【００６９】
送信装置は、ルータのルーティングプロトコルインタフェースを使用してローカルルータとのインタフェース機能を行うことによって、照会のためのルーティングツリー全体を取り出すことができる。特定の実施例によると、指定された照会ノードを、このルーティングツリー内の主要分岐ポイントに配置できる。いくつかの特定の実施例によると、指定された照会ノードを配置するための最良の位置を計算するためには、必要かつ十分な情報として、ルーティングツリー自体と、指定された照会ノードになることのできるツリー上のより良好なルーティングノードの位置の両方が必要である。しかしながら、基礎となるルーティングシステムによって、さまざまなツリーセグメントのネットワーク帯域幅制約や、各受信装置において格納されている照会に関連する情報の量などの追加の情報も報告される場合には、照会プランニングにおいて、指定された照会ノードを決定するときにこれらの変数も考慮できる。
【００７０】
望ましい実施例によると、送信装置は、ルーティングツリーとより良好なノードの情報を使用して、すべての受信装置と送信装置の間の重心位置を決定することができる。この重心は、実質的に照会の「質量中心」である。従って、この重心は、ジョインするために各受信装置からの照会関連データを中央ポイントまで移動するためのコストが等しくなるポイントである。このコスト分析においては、以下の点数システムの例を使用できる。
・  各データタプル（行）に1点が与えられる。
・  各ネットワークホップに1点が与えられる。
・  ネットワークセグメントには、その帯域幅制約に基づいて点数が与えられる。帯域幅能力の高いセグメントには、低い帯域幅のセグメントより高い点数が与えられる。
・  その他のポイントには、ルーティングツリー上のより良好なルーティングノードの処理能力など、他の基準に基づいて点数を与えることができる。
【００７１】
例えば、ルーティングツリーのみが分かっている場合には、重心は、すべての受信装置および送信装置から等しい距離にある位置である。各ノードにおいて格納されている照会関連情報の量など追加の情報が考慮される場合には、重心は、そこを通る線を引くと、線の片側の照会関連のデータ量が反対側とちょうど同じになるような、中央値ポイントとなる。
【００７２】
この重心位置にもっとも近い指定された照会ノードが、「指定された照会ノード」になる。この指定された照会ノードは、照会の断片(fragments)を発行して相互に関連するデータを集め、データをジョインし、送信装置（照会側ノード）にのみ応答を送り返すことによって、副照会を完全に実行する。指定された照会ノードが使用される特定の実施例においては、照会側ノードのネットワークインタフェースが適切なタイプのデータソースからの応答を集めるステップ（図2におけるステップ110）の前に、関連データソースに関連付けられる指定された照会ノードが処理を実行するステップと、指定された照会ノードが照会側ノードに応答メッセージを送信するステップとが行われる。
【００７３】
III.  宣言型機能をプッシュすることによるイベントベース能力の達成
代替の実施例は、「関数」とオプションとしての「関数本体」とを指定することによって、オプションの追加の仕様によって従来のデータベース照会を拡張する。指定された関数は、送信装置側、データソース側、または指定された照会ノードにおいて実行できる。一般的には、これによって、ネットワークトラフィックを低減させることを目的として、アドホック的または場合によっては一時的にデータ処理機能を追加することができる。さらに、このメカニズムを使用して、新しいグローバルスキーマとローカル／グローバルスキーマ間のマッピングの一方または両方をデータソースノードに分散させることができる。このような関数を送信することによって、この能力は、オプションのリフレッシュレートなどの他の能力を包含する。リフレッシュレートは、代わりに、指定された期間だけスリープした後に照会を再実行する関数として指定できる。
【００７４】
照会およびその照会制約と共に、1つ以上の関数内の宣言型ステップの形式で機能をプッシュすることによって、この実施例にイベントベース能力が備わる。イベントは、照会の制約によって定義され、関数内の宣言型ステップによってさらに定義または細密に定義される。さらに、イベントが起きたときにとるアクションを、関数内の宣言型ステップの一部として指定できる。
【００７５】
A.  データ管理機能の分散
この実施例においては、ユーザが照会の中で関数を指定する方法はいくつかあり、例えば次のとおりである。
・  （照会の「select」部分において）照会によって生成される情報に対して作用するもの
・  副照会から生成される情報に対して作用するもの
・  ジョインからの情報に作用するもの
・  制約フィールドに作用するもの
・  パラメータをとらず、単に照会の一部として制約を提供する。この場合には、関数は照会の中でパラメータをとらないが、SQLなどのデータ照会言語の範囲を超える他の情報、例えばデータ応答に影響を与えうる認識されている弱点がデータソースの主プロセッサに存在しないか否かのテストの情報などを、データソースノードから直接的に集めることができる。
【００７６】
特定の実施例によると、照会は関数本体も指定できる。この関数本体は、JavaまたはTCLなどの宣言型インタプリタ言語で書かれる。この場合、ユーザは、関数の「クロージャ」が含まれることを照会の中に指定する。次いで、ユーザは、クロージャ文の一部として関数コードを書くか、または関数本体を含むファイルを指定するかのいずれかによって、関数本体を指定する。
【００７７】
特定の実施例によると、各データソースに対する照会メッセージの関与部分（関数情報を含む）は、次のとおりである。
1.  制約のリスト（場合によっては空）。データソースは情報を送信するか否かをこのリストに基づいて決定する必要がある。制約には、関数の名前と、関数の入力パラメータであるテーブルフィールドと属性フィールドが含まれる。
2.  制約が満たされている場合にデータソースが戻す必要のある戻り値のリスト。
3.  オプションとして、関数のクロージャセクションには、各関数とその関数本体とがリストされる。
4.  一意のメッセージID
5.  照会側ノードのアドレス
システムは、次いで、各メッセージをネットワークを通じて送信する。
【００７８】
B.  データソースの機能のインストール
この実施例によると、データジョイン装置（すなわち指定されたジョインまたは指定された照会ノード）およびデータソース（すなわちローカルなジョイン装置）とのプログラムインタフェースを提供するために、インタプリタ言語またはジャストインタイム（JIT）コンパイラが使用される。JITまたはインタプリタ言語では、ユーザはアドホック的に機能を作成し、それを照会と一緒にプッシュすることにより、データソース側において用途に固有な計算を実行させることができる。このような機能は、照会の存続期間の間だけ一時的に格納され、その後削除される。これに代えて、管理者は、システムのユーザに提供される関数の標準ライブラリと一緒に、データジョイン装置またはデータソースをプリロードできる。管理者は、ライブラリを動的に調整することによって、機能の永久的な追加または削除を容易に行うことができる。
【００７９】
以下は、データ処理用の命令の分散の使用例である。
1)  オブジェクト指向のデータソースへのオブジェクトクラスのメソッドの分散。
2)  平均計算、デルタ抽出（大きなデータセットにおける変更のみを報告する）、ピーク抽出、ハッシュ化など、データ低減命令の分散。
3)  データ圧縮の命令の分散。
4)  大きなデータセットから関連する要約を抽出するトレンド分析命令の分散。
スキーマとスキーママッピングを分散させるため、この実施例は、各翻訳をライブラリ関数にすることによってスキーマの翻訳を動的にする。ローカル管理者は、このライブラリ関数を調整することによって、標準の関数を自身のサイトの設備構成に合わせてローカライズできる。これは、ローカルデータストア用のソフトウェア「ドライバ」を書くことに似ている。データ管理システムには、SQLデータベースなど、一般的なデータソース用のデフォルト関数を設けることができる。グローバルシステムの管理者は、標準ライブラリインタフェースを対象とする翻訳関数として、自身のグローバルスキーマの変更を伝えることもできる。
【００８０】
C.  照会のリフレッシュの終了
特定の実施例によると、関数が指定されている照会は、終了されるまで継続する。いずれのノードも、照会の中で参照されているデータソースタイプを満たす各データソースに特殊な「照会の終了」メッセージを送信することによって、照会を終了させることができる。この終了メッセージには、終了させるネットワークメッセージのメッセージIDが含まれる。次いで、データソースのネットワークインタフェースは、自身の未処理照会のリストからそのネットワークメッセージを削除する。
【００８１】
オプションとして、前述されているように、各データソースまたは指定された照会ノードのネットワークインタフェースがネットワークメッセージをその寿命が経過した後に自動的に削除するように、照会、データソース、または指定された照会ノードのいずれかに「MaximumReplyLifetime」を割り当てることができる。このことは、指定された照会ノードまたはデータソースに機能をプッシュするときに特に重要となり、なぜなら、関数自体において例外が発生して動作不能または非応答状態になることがあるためである。MaxiumumReplyLifetimeの値は、各データソースごとにケースバイケースで決定するか、または設定されるデフォルト値によって指定できる。データソースのソフトウェアまたは指定された照会ノード内の個別のスレッドは、MaxiumumReplyLifetimeより過去に受信された応答メッセージがないか、バッファすべてを継続的にチェックする。このようなメッセージが見つかると、バッファから削除される。照会が終了される時点において、照会側ノードは、バッファ内にまだ存在している、その照会に関連する応答メッセージも消去する。
【００８２】
IV.  アクセスできないデータソースの扱い
広く分散されたシステムは、実際には、信頼性の低い通信（多数の無線プロトコル、サードパーティのインターネットサービスプロバイダからのサービスの停止など）に起因して一時的なサービス停止が起きやすい。本発明の特定の実施例によると、アーカイブを使用することにより、システムの堅牢性を向上させることができる。アーカイブは、1つ以上のデータソースを定期的にポーリングしてその値を記録するデータ収集装置である。また、アーカイブは、自身が特定のデータソースのアーカイブであることを示すために特性を公表する。応答しないデータソースに要求が出された場合には、これらの特定の実施例によるシステムは、その要求をアーカイブに再ルーティングできる。受信されるデータは、必ずしも現在のものではないが、いくつの用途においては、データがないよりも古いデータでも得られる方が望ましい。
【００８３】
再ルーティング能力は、基礎となるルーティングシステムか、本システムのクライアント側の照会ソフトウェアのいずれかに実施できる。前者の場合には、ルータは、隣接するデータソースが応答しない場合にアーカイブからのデータを供給する責任を持つ。後者の場合には、ネットワークが、正常にアクセスされたデータソースのリストを提供し、照会ソフトウェアが、その成功リストを含む要求をアーカイブに再送信する。次いで、アーカイブは、自身がルーティング特性に合致しかつ成功リストに含まれていないデータソースを表すならば、それに応答する。
【００８４】
V.  結論
上記の説明は、さまざまな特定の実施例を例解するが、理解すべき点とて、本発明は、説明されている実施例に必ずしも限定されない。説明されている実施例のバリエーションまたは変更を本発明の範囲から逸脱することなく構築できる。本発明は、添付の請求項によってのみ制限される。
【図面の簡単な説明】
【００８５】
【図１】本発明を採用できるネットワークアーキテクチャの例を示す。
【図２】本発明の特定の実施例の全般的な機能の説明を示す。
【図３】本発明の特定の実施例による、データベース照会をネットワークメッセージに翻訳するための機能の説明を示す。
【図４】本発明の特定の実施例による、受信されたネットワークメッセージを処理するネットワークインタフェースの機能の説明を示す。
【図５Ａ】本発明の特定の実施例による、ネットワークメッセージを集めて照会結果を解釈するための機能の説明を示す。
【図５Ｂ】本発明の特定の実施例による、ネットワークメッセージを集めて照会結果を解釈するための機能の説明を示す。
【図５Ｃ】本発明の特定の実施例による、ネットワークメッセージを集めて照会結果を解釈するための機能の説明を示す。
【図６】特定の実施例による、郵便ロジスティクス用途に使用できる単純化されたデータスキーマを示す。
【図７】本発明の特定の実施例による、非ローカルジョインを含む照会と、生成された述語グループの例を示す。
【図８】図7の例による、メッセージ2の可能なテキストを示す。%1は、リストされるデータに置き換わるプレースホルダを示す。
【符号の説明】
【００８６】
15  ネットワークルータ
20  データ生産装置
25  データ消費装置
30  データ生産装置／消費装置
35  ライン
【図１】
2006503342.tif 000003
【図２】
2006503342.tif 000004
【図３】
2006503342.tif 000005
【図４】
2006503342.tif 000006
【図５Ａ】
2006503342.tif 000007
【図５Ｂ】
2006503342.tif 000008
【図５Ｃ】
2006503342.tif 000009
【図６】
2006503342.tif 000010
【図７】
2006503342.tif 000011
【図８】
2006503342.tif 000012
【手続補正書】
【提出日】平成17年1月6日(2005.1.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１
【補正方法】変更
【補正の内容】
【請求項１】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が、少なくとも1つのテーブル名と、少なくとも1つのテーブル属性と、少なくとも1つのテーブル属性の値とを含む、ステップと、
当該照会を、テーブル名と、テーブル属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の中の当該テーブル名と、当該テーブル属性と、当該値の当該特定のセットに関連するデータソースに伝送するステップと、
当該照会が満たされるときに、当該照会の当該テーブル名と、当該テーブル属性と、当該値の当該特定のセットに関連する当該データソースから少なくとも1つの応答メッセージを受信するステップと、
当該少なくとも1つの応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップと、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的又は能動的でないの何れかに選択可能なリフレッシュレートを提供するステップと、
を有する、方法。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項９
【補正方法】変更
【補正の内容】
【請求項９】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が、少なくとも1つのクラス名と、少なくとも1つのクラス属性と、少なくとも1つのクラス属性の値とを含む、ステップと、
当該照会を、クラス名と、クラス属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の中の当該クラス名と、当該クラス属性と、当該値の当該特定のセットに関連するデータソースに伝送するステップと、
当該照会が満たされているときに、当該照会の当該クラス名と、当該クラス属性と、当該値の当該特定のセットに関連する当該データソースから少なくとも1つの応答メッセージを受信するステップと、
当該少なくとも1つの応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップと、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的又は能動的でないの何れかに選択可能なリフレッシュレートを提供するステップと、  を有する、方法。
【手続補正３】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項１７
【補正方法】変更
【補正の内容】
【請求項１７】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が、少なくとも1つのタグ名と、少なくとも1つのタグ属性と、少なくとも1つのタグ属性の値とを含む、ステップと、
当該照会を、タグ名と、タグ属性と、値の特定のセットを含む少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の中の当該タグ名と、当該タグ属性と、当該値の当該特定のセットに関連するデータソースに伝送するステップと、
当該照会が満たされているときに、当該照会の当該タグ名と、当該タグ属性と、当該値の当該特定のセットに関連する当該データソースから少なくとも1つの応答メッセージを受信するステップと、
当該少なくとも1つの応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップと、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的又は能動的でないの何れかに選択可能なリフレッシュレートを提供するステップと、 
を有する、方法。
【手続補正４】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項２５
【補正方法】変更
【補正の内容】
【請求項２５】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードおよび複数のデータソースと、特定のデータソースを表す複数のアーカイブノードとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップと、
当該照会を少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会に関連するデータソースに伝送するステップと、
正常にアクセスされたデータソースのリストを当該ネットワークから受信するステップと、
当該ネットワークメッセージを当該アーカイブノードと当該リスト上のデータソースとに再伝送するステップと、
当該リストからの当該データソースからと、当該照会に合致するが当該リスト上にないデータソースを表す当該アーカイブノードとから、応答メッセージを受信するステップと、
当該応答メッセージに基づいて照会結果を当該データベース言語において提供するステップと、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的又は能動的でないの何れかに選択可能なリフレッシュレートを提供するステップと、
を有する、方法。
【手続補正５】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項３１
【補正方法】変更
【補正の内容】
【請求項３１】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップであって、当該スキーマが、ローカルにジョイン可能な記述子のリストを提供する、ステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が複数の述語を含む、ステップと、
当該照会を少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会の当該複数の述語に関連するデータソースに伝送するステップと、
当該ローカルにジョイン可能な記述子のリストに含まれる当該照会の述語が当該データソースにおいてローカルにジョインされるときに、当該ネットワークメッセージへの応答メッセージを、当該照会に関連する当該データソースから受信するステップと、
当該応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップと、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的又は能動的でないの何れかに選択可能なリフレッシュレートを提供するステップと、 
を有する、方法。
【手続補正６】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項３７
【補正方法】変更
【補正の内容】
【請求項３７】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと少なくとも1つの指定された照会ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップであって、当該照会が複数の副照会を含む、ステップと、
当該照会を、複数のネットワークメッセージに分解するステップであって、当該複数のネットワークメッセージの1つが、当該複数の副照会に対応する、ステップと、
当該複数のネットワークメッセージの1つを、当該照会の当該複数の副照会の当該1つに関連する指定された照会ノードに伝送するステップであって、当該少なくとも1つの指定された照会ノードが、当該複数の副照会の当該1つを処理し、かつ、当該照会の断片を、当該照会の断片に関連しかつ当該少なくとも1つの指定された照会ノードが責任を持つ対象のデータソースに伝送する、ステップと、
当該照会の断片への応答がジョインされかつ当該照会が満たされるときに、当該少なくとも1つの指定された照会ノードから、当該ネットワークメッセージへの応答メッセージを受信するステップと、
当該応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップと、
照会の断片が、一定のリフレッシュレートにおいて関連データソースにより定期的にチェックされることを示す、その当該の照会に対して選択可能なリフレッシュレートを提供するステップであって、選択可能な当該リフレッシュレートが能動的か能動的でないか選択可能なステップと、
を有する、方法。
【手続補正７】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項４６
【補正方法】変更
【補正の内容】
【請求項４６】
複数のノードを有する分散型データソースネットワークデータベースの情報管理のための方法であって、当該複数のノードが、照会側ノードと複数のデータソースとを含み、当該方法が、
当該分散型データソースネットワークデータベース用のスキーマを提供するステップと、
1つ以上の関数を少なくとも1つのノードに分散させるステップと、
データベース言語での照会を当該ネットワーク内の当該照会側ノードに入力するステップと、
当該照会を少なくとも1つのネットワークメッセージに分解するステップと、
当該ネットワークメッセージを、当該照会に関連するデータソースに伝送するステップと、
当該照会が満たされかつ当該1つ以上の関数が適用されるときに、当該ネットワークメッセージへの応答メッセージを、当該照会に関連する当該データソースから受信するステップと、
当該応答メッセージからの照会結果を当該データベース言語において当該照会側ノードに提供するステップと、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的又は能動的でないの何れかに選択可能なリフレッシュレートを提供するステップと、
を有する、方法。
【手続補正８】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項５６
【補正方法】変更
【補正の内容】
【請求項５６】
データソースのネットワークを有する分散型データベースの情報管理のためのシステムであって、当該システムが、
当該ネットワークに結合されている複数のデータソースであって、当該データソースが、当該分散型データベースのスキーマに従って情報を提供することのできる、データソースと、
当該ネットワークに結合されている少なくとも1つの照会側ノードであって、当該照会側ノードが、データベース言語での照会を受信し、かつ、当該照会を、当該照会に関連するデータソースに当該ネットワークを通じて伝送される少なくとも1つのネットワークメッセージに分解することができる、照会側ノードと、
を有するシステムであって、
当該照会に関連するデータソースが、当該照会が満たされるときに当該ネットワークメッセージに応答して応答メッセージを当該ネットワークを通じて送信し、かつ、当該照会側ノードが、当該応答メッセージからの照会結果を当該データベース言語において提供し、
当該照会が、指定されたリフレッシュレートで関連データソースにより周期的にチェックされることを示す当該照会に対して、能動的か能動的でないか選択可能でないの何れかに選択可能なリフレッシュレートを含み、かつ、
当該複数のデータソースが、当該照会に対するローカルジョインを実行することのできる少なくとも1つのデータソースを含む、
システム。
【国際調査報告】
2006503342.tif 000013
2006503342.tif 000014
2006503342.tif 000015
2006503342.tif 000016