"データ管理システムであって、共通のフォームを有する独立した複数のデータ構造であって、複数の前記データ構造夫々は、単一のデータインスタンスをカプセル化し、また、複数の前記データ構造夫々は、関連するデータインスタンスをカプセル化した他の独立した前記データ構造への複数の参照をカプセル化する、複数の前記データ構造を含み、当該複数のデータ構造は、非テーブル形式にて、コンピューターにより読み取り可能な媒体に格納されており、更に、前記データ構造においてカプセル化された前記データインスタンスは、追加、削除、及び検索可能である、データ管理システム。独立した前記データ構造各々は、前記データ構造の多次元編成内における自身の位置を示す参照もカプセル化することを特徴とする請求項1に記載のデータ管理システム。第1のデータインスタンスが、関連するデータインスタンスへの複数の参照と共にカプセル化され、各関連するデータインスタンスが、カプセル化された前記第1のデータインスタンスへの参照と共に個別にカプセル化されることを特徴とする、請求項1又は2に記載のデータ管理システム。第1のデータインスタンスは、関連するデータインスタンスへの複数の参照と共にカプセル化され、各関連するデータインスタンスは、カプセル化された前記第1のデータインスタンスへの参照と共に個別にカプセル化され、各々の前記カプセル化された参照は、各々の前記関連するカプセル化されたデータインスタンスを一意に識別する論理インデックスであり、コンピューターにより読み取り可能な媒体上における、各々の前記関連するカプセル化されたデータインスタンスのロケーションを符号化したものであり、そして、前記論理インデックスはm次元であり、1次元毎にnビットを有することを特徴とする、請求項1乃至3のいずれか一項に記載のデータ管理システム。前記カプセル化された複数の前記参照が、少なくとも1つの次元にあり、および各々の前記少なくとも1つの次元が、関連のタイプに対応することを特徴とする、請求項1乃至4のいずれか一項に記載のデータ管理システム。前記カプセル化された複数の前記参照が、少なくとも1つの次元にあり、および各々の前記少なくとも1つの次元が、関連のタイプに対応する、請求項1乃至5のいずれか一項に記載のデータ管理システムであって、前記少なくとも1つの次元が、前記カプセル化された複数の参照を有する、データ管理システム。前記データ構造がアプリケーションに依存せず、全ての前記データインスタンスに対して一般的に同じであることを特徴とする、請求項1乃至6のいずれか一項に記載のデータ管理システム。前記カプセル化された複数の前記参照の少なくとも1つが、他のコンピューティング環境のカプセル化されたデータインスタンスへの参照であることを特徴とする、請求項1乃至7のいずれか一項に記載のデータ管理システム。前記カプセル化されたデータインスタンスの少なくとも1つの前記カプセル化された参照が一意であり、前記カプセル化されたデータインスタンスの少なくとも2つの前記カプセル化された参照が一般に同一であることを特徴とする、請求項1乃至8のいずれか一項に記載のデータ管理システム。予め確立された関連を有する複数の既存のカプセル化されたデータインスタンスを含み、ここで、少なくとも1つの新しいカプセル化されたデータインスタンスが、前記既存のカプセル化されたデータインスタンスの少なくとも1つと関連付けられていることを特徴とする、請求項1乃至9のいずれか一項に記載のデータ管理システム。予め確立された関連を有する複数の既存のカプセル化されたデータインスタンスを含み、ここで、当該システムによる処理に応じて、任意の前記既存のカプセル化されたデータインスタンスが、削除され、他の既存の関連するカプセル化されたデータインスタンスとの関連が解消されることを特徴とする、請求項1乃至10のいずれか一項に記載のデータ管理システム。予め確立された関連を有する複数の既存のカプセル化されたデータインスタンスを含み、ここで、当該データ管理システムによる処理に応じて、少なくとも2つの既存のカプセル化されたデータインスタンスの間の新しい関連が追加できることを特徴とする、請求項1乃至11のいずれか一項に記載のデータ管理システム。予め確立された関連を有する複数の既存のカプセル化されたデータインスタンスを含み、ここで、当該データ管理システムによる処理に応じて、前記既存のカプセル化されたデータインスタンスの間の前記既存の関連の幾つかが削除できることを特徴とする、請求項1乃至12のいずれか一項に記載のデータ管理システム。選択基準を表現する既知のカプセル化されたデータインスタンスにアクセスすることにより、既知のカプセル化されたデータインスタンスの前記選択基準から特定の不明のカプセル化されたデータインスタンスを見出す検索機能を含み、当該検索機能は、前記選択基準を表現する前記既知のカプセル化されたデータインスタンスを用いてカプセル化された参照にアクセスし、前記特定の不明のカプセル化されたデータインスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および前記特定の不明のカプセル化されたデータインスタンスを検索することを更に含むことを特徴とする、請求項1乃至13のいずれか一項に記載のデータ管理システム。前記カプセル化された複数の前記参照が、複数次元の論理インデックスであり、前記各次元が、関連のタイプに対応し、および前記アクセスが、前記選択基準で指定された前記次元からの前記カプセル化された参照へのアクセスを更に含むことを特徴とする、請求項14に記載のデータ管理システム。前記カプセル化された複数の前記参照が、m次元論理インデックスであり、各々は、コンピューターにより読み取り可能な媒体上における前記関連するカプセル化されたデータインスタンスのロケーションを一意に識別して符号化したものであり、および前記m次元論理インデックスの少なくとも1つでのブール演算により前記カプセル化された参照をフィルタすることを更に含むことを特徴とする、請求項14又は15に記載のデータ管理システム。前記ブール演算が、単一の演算における前記比較の結果から少なくとも1つのカプセル化された参照を直接排除させる基本的な算術演算を更に含むことを特徴とする、請求項14乃至16のいずれか一項に記載のデータ管理システム。前記カプセル化されたデータインスタンスが、ユーザインターフェースの属性を有することを特徴とする、請求項1乃至17のいずれか一項に記載のデータ管理システム。ユーザインターフェースの前記属性が、ユーザビュー、表示要素、およびデータアクセス方法のグループから選択されることを特徴とする、請求項18に記載のデータ管理システム。2以上の異なる前記カプセル化されたデータインスタンスの前記カプセル化された複数の参照が、所望する結果を導出するために使用される態様にて、前記システムを検索することを特徴とする、請求項1乃至19のいずれか一項に記載のデータ管理システム。2以上の異なる前記カプセル化されたデータインスタンスの前記カプセル化された複数の参照が、共通性、類似性、および差異の少なくとも1つにおいて比較され、前記所望する結果に対応する前記参照のセットを導出することを特徴とする、請求項20に記載のデータ管理システム。2以上の異なる前記カプセル化されたデータインスタンスの前記カプセル化された参照が値に基づく順番により記憶されており、共通性、類似性、および差異の少なくとも1つにおいて比較され、前記所望する結果に対応する参照のセットを導出することを特徴とする、請求項21に記載のデータ管理システム。第1のデータインスタンスは、関連するデータインスタンスへの複数の参照と共にカプセル化され、前記各関連するデータインスタンスは、カプセル化された前記第1のデータインスタンスへの参照と共に個別にカプセル化され、各々の前記カプセル化された参照は、各々の前記関連するカプセル化されたデータインスタンスを一意に識別する論理インデックスであり、コンピューターにより読み取り可能な媒体上における、各々の前記関連するカプセル化されたデータインスタンスのロケーションも符号化したものであり、そして、前記論理インデックスはm次元であり、1次元毎にnビットを有し、2以上の異なる前記カプセル化されたデータインスタンスの前記カプセル化された複数の参照が、共通性、類似性、および差異の少なくとも1つにおいて比較して前記所望する結果に対応する参照のセットを導出することに使用されることを特徴とする、請求項20に記載のデータ管理システム。前記少なくとも1つの次元が、複数の前記カプセル化された参照を有し、および2以上の異なる前記カプセル化されたデータインスタンスの前記カプセル化された複数の参照が値に基づく順番により記憶され、共通性、類似性、および差異の少なくとも1つにおいて比較され、前記所望する結果に対応する参照のセットを導出することを特徴とする、請求項20に記載のデータ管理システム。ASCII文字を表現する、カプセル化された複数のデータインスタンスを更に含み、ASCII文字を表現する前記カプセル化されたデータインスタンスを含む前記データ構造も、1以上の前記対応するASCII文字による、カプセル化されたデータインスタンスへのカプセル化された参照を含み、および1以上の前記ASCII文字による、前記カプセル化されたデータインスタンスを含む前記データ構造も、使用されたASCII文字を表現する前記カプセル化されたデータインスタンスへのカプセル化された参照を含むことを特徴とする、請求項1乃至24のいずれか一項に記載のデータ管理システム。所定のASCII文字データインスタンスを有する前記カプセル化された参照が、前記カプセル化されたデータインスタンスの前記ASCII文字の順番における前記所定のASCII文字の位置に基づいて、前記ASCII文字を用いた他のカプセル化されたデータインスタンスを参照することを特徴とする、請求項25に記載のデータ管理システム。ユニコード文字を表現する、前記カプセル化された複数のデータインスタンスを更に含み、ユニコード文字を表現する前記カプセル化されたデータインスタンスを含む前記データ構造も、1以上の前記ユニコード文字を用いた、カプセル化されたデータインスタンスへのカプセル化された参照を含み、および1以上のユニコード文字を用いた、前記カプセル化されたデータインスタンスを含む前記データ構造も、使用された前記ユニコード文字を表現する前記データインスタンスへのカプセル化された参照を含むことを特徴とする、請求項1乃至24のいずれか一項に記載のデータ管理システム。所定のユニコード文字データインスタンスを有する前記カプセル化された参照が、前記カプセル化されたデータインスタンスの前記ユニコード文字の順番における前記所定のユニコード文字の位置に基づいて、前記ユニコード文字を用いて他のデータインスタンスを参照することを特徴とする、請求項27に記載のデータ管理システム。任意のデータ型のトークンセットを表現するカプセル化された複数のデータインスタンスを含み、前記トークンを指標する前記データインスタンスを含む前記データ構造も、1以上の前記トークンを使用してカプセル化されたデータインスタンスへのカプセル化された参照を含み、1以上の前記トークンを使用してカプセル化されたデータインスタンスを含む前記データ構造も、前記使用されたトークンを示す前記カプセル化されたデータインスタンスへのカプセル化された参照を含むことを特徴とする、請求項1に記載のデータ管理システム。所定のトークンセットのためにカプセル化された参照は、前記カプセル化されたデータインスタンスにおける前記トークンの順番における前記所定のトークンの位置に基づいて、トークンを用いてカプセル化された他のデータインスタンスを参照することを特徴とする、請求項29に記載のデータ管理システム。前記トークンセットが、1組のグラフィック記述子、1組の色、1組の形状、1組のグリフ、1組の波形、1組の周波数値、1組の可聴周波数値、定義されたシンボルのセット、および実数のグループから選択されることを特徴とする、請求項30に記載のデータ管理システム。前記データ構造がアプリケーションに依存せず、全ての前記データインスタンスに対して一般的に同じであり、選択基準を表現する前記既知のカプセル化されたデータインスタンスにアクセスすることにより、既知のカプセル化されたデータインスタンスの前記選択基準から特定の不明のカプセル化されたデータインスタンスを見出し、前記選択基準を表現する前記既知のカプセル化されたデータインスタンスを用いてカプセル化された参照にアクセスし、前記特定の不明のカプセル化されたデータインスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および前記特定の不明のカプセル化されたデータインスタンスを検索することを特徴とする、請求項1に記載のデータ管理システム。異なる前記カプセル化されたデータインスタンスの前記カプセル化された参照が、所望する結果を導出するために使用される態様にて、前記システムを検索することを特徴とする、請求項32に記載のデータ管理システム。前記カプセル化された参照の少なくとも1つが、他のコンピューティング環境のカプセル化されたデータインスタンスへの参照であり、および第1のデータインスタンスが、関連するデータインスタンスへの複数の参照と共にカプセル化され、各関連するデータインスタンスが、カプセル化された前記第1のデータインスタンスへの参照と共に個別にカプセル化されることを特徴とする、請求項1に記載のデータ管理システム。前記カプセル化されたデータインスタンスの少なくとも1つの前記カプセル化された参照が一意であり、前記カプセル化されたデータインスタンスの少なくとも2つの前記カプセル化された参照が一般に同一であり、選択基準を表現する前記既知のカプセル化されたデータインスタンスにアクセスすることにより、既知のカプセル化されたデータインスタンスの前記選択基準から特定の不明のカプセル化されたデータインスタンスを見出し、前記選択基準を表現する前記既知のカプセル化されたデータインスタンスを用いてカプセル化された参照にアクセスし、前記特定の不明のカプセル化されたデータインスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および前記特定の不明のカプセル化されたデータインスタンスを検索することを特徴とする、請求項1に記載のデータ管理システム。前記カプセル化されたデータインスタンスの少なくとも1つの前記カプセル化された参照が一意であり、および前記カプセル化されたデータインスタンスの少なくとも2つの前記カプセル化された参照が一般に同じであり、および異なる前記カプセル化されたデータインスタンスの前記カプセル化された参照が、所望の結果を導出するために使用される態様にて、前記システムをサーチすることを特徴とする、請求項1に記載のデータ管理システム。データ管理システムであって、共通のフォームを有する独立した複数のデータ構造であって、前記データ構造夫々は、単一のデータインスタンスをカプセル化する、複数のデータ構造を含み、前記複数のデータ構造は、非テーブル形式にて、コンピューターにより読み取り可能な媒体に格納されており、各々のカプセル化される参照は、各々の前記関連するカプセル化されたデータインスタンスを一意に識別する論理インデックスであり、コンピューターにより読み取り可能な媒体上における、各々の前記関連するカプセル化されたデータインスタンスのロケーションも符号化したものであり、前記論理インデックスはm次元であり、1次元毎にnビットを有し、前記カプセル化された参照が、少なくとも1つの次元にあり、各々の前記少なくとも1つの次元が、関連のタイプに対応することを特徴とする、データ管理システム。前記データ構造がアプリケーションに依存せず、全ての前記データインスタンスに対して一般的に同じであることを特徴とする、請求項37に記載のデータ管理システム。選択基準を表現する既知のカプセル化されたデータインスタンスにアクセスすることにより、既知のカプセル化されたデータインスタンスの前記選択基準から特定の不明のカプセル化されたデータインスタンスを見出す検索機能を含み、当該検索機能は、前記選択基準を表現する前記既知のカプセル化されたデータインスタンスを用いてカプセル化された参照にアクセスし、前記特定の不明のカプセル化されたデータインスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および前記特定の不明のカプセル化されたデータインスタンスを検索することを更に含むことを特徴とする、請求項38に記載のデータ管理システム。前記システムを検索し、異なる前記カプセル化されたデータインスタンスの前記カプセル化された参照が、所望の結果を導出するために使用されることを特徴とする、請求項39に記載のデータ管理システム。前記カプセル化された参照の少なくとも1つが、他のコンピューティング環境のカプセル化されたデータインスタンスへの参照であることを特徴とする、請求項40に記載のデータ管理システム。前記カプセル化されたデータインスタンスの少なくとも1つの前記カプセル化された参照が一意であり、前記カプセル化されたデータインスタンスの少なくとも2つの前記カプセル化された参照が一般に同一であることを特徴とする、請求項41に記載のデータ管理システム。前記システムを検索し、異なる前記カプセル化されたデータインスタンスの前記カプセル化された参照が、所望する結果を導出するために使用されることを特徴とする、請求項42に記載のデータ管理システム。選択基準を表現する既知のカプセル化されたデータインスタンスにアクセスすることにより、既知のカプセル化されたデータインスタンスの前記選択基準から特定の不明のカプセル化されたデータインスタンスを見出す検索機能を含み、当該検索機能は、前記選択基準を表現する前記既知のカプセル化されたデータインスタンスを用いてカプセル化された参照にアクセスし、前記特定の不明のカプセル化されたデータインスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および前記特定の不明のカプセル化されたデータインスタンスを検索することを更に含むことを特徴とする、請求項37に記載のデータ管理システム。2以上の異なる前記カプセル化されたデータインスタンスの前記カプセル化された参照が、所望する結果を導出するために使用される態様にて、前記システムを検索することを特徴とする、請求項44に記載のデータ管理システム。前記カプセル化された参照の少なくとも1つが、他のコンピューティング環境のカプセル化されたデータインスタンスへの参照であることを特徴とする、請求項37に記載のデータ管理システム。前記カプセル化されたデータインスタンスの少なくとも1つの前記カプセル化された参照が一意であり、前記カプセル化されたデータインスタンスの少なくとも2つの前記カプセル化された参照が一般に同一であることを特徴とする、請求項37に記載のデータ管理システム。コンピュータにより実行される、データインスタンス中心でないデータベースを、データインスタンス中心データベースに変換するための方法であって、前記データインスタンス中心でないデータベーススキーマの要素、および前記データインスタンス中心でないデータベースのデータ要素を表現する前記データインスタンス中心データベースにおいて、カプセル化されたデータインスタンスを創出し、前記データインスタンス中心でないデータベースの前記データ要素と前記スキーマ要素との間の関係を表現する前記データインスタンス中心データベースにおいて、前記データインスタンス間の関連を創出し、関連するデータインスタンスをカプセル化する共通のフォームを有する独立したデータ構造内に記憶された関連するデータインスタンスに、前記関係を参照として記憶する手順を含み、これらは、コンピューターにより読み取り可能な媒体上に、非テーブル形式にて記憶される、方法。前記変換が、前記データインスタンス中心データベースのデータインスタンスであるソフトウェアエージェントによることを特徴とする、請求項48に記載の方法。前記データインスタンス中心でないデータベースが、単層ファイルを含むことを特徴とする、請求項49に記載の方法。データ管理システムであって、1以上のアイテムを含み、前記各アイテムが、データインスタンスをカプセル化し、および前記各アイテムが、互いの相互参照をカプセル化して相互間にて関連付けられており、前記アイテムは、当該データ管理システムにより、追加され、削除され、及び検索され、前記アイテムは、コンピューターにより読み取り可能な媒体上に、非テーブル形式にて記憶される、データ管理システム。前記各アイテムが、基本的なデータ構造で表されることを特徴とする、請求項51に記載のデータ管理システム。前記各アイテムが、アイテムに関連する一意な参照を有することを特徴とする、請求項51又は52に記載のデータ管理システム。前記一意な参照も、前記コンピューターにより読み取り可能な媒体上において前記各アイテムに関連する前記データインスタンスを物理的に配置するインデックスとして機能することを特徴とする、請求項53に記載のデータ管理システム。前記参照が、前記アイテムとセットで参照された他の各アイテムの間の関連の型を定義する前記セットで配置されるアイテムに関連付けられることを特徴とする、請求項51乃至54のいずれか一項に記載のデータ管理システム。前記各参照がm次元インデックスであり、前記各次元がnビット長であることを特徴とする、請求項53に記載のデータ管理システム。mが4であり、nが30であることを特徴とする、請求項56に記載のデータ管理システム。前記アイテムが、1または複数の他のメンバアイテムのためのコンテナとして機能することを特徴とする、請求項51に記載のデータ管理システム。コンテナアイテムの内部のアイテムのメンバシップが、前記コンテナアイテムおよび前記各メンバアイテムの前記論理インデックスの1または複数の前記m次元の識別により示されることを特徴とする、請求項58に記載のデータ管理システム。前記各アイテムが、埋込要素をカプセル化することを特徴とする、請求項51に記載のデータ管理システム。前記埋込要素が、他のアイテムへの参照であることを特徴とする、請求項60に記載のデータ管理システム。前記データインスタンスが、任意の型のデータを含むことを特徴とする、請求項51に記載のデータ管理システム。上記のように、KnOS設計は、レコードに基づくリレーショナル、階層的、ネットワークDBMSと関連する問題を解決する。KnOS発明の目的は、現世代DBMSをリレーショナル、階層的、ネットワーク、またはOLTPおよびDWHの両方を含む他の現在実施されているデータモデル上で押しのけて取って代わることである。一般に、本発明は、ソフトウェアを1または複数のコンピュータと一緒に使用する方法により実施される。図28に示されるように、本発明はコンピュータハードウェアおよびソフトウェアを用いて実施される。図28の実施例では、入力および出力がKnOSプロセッサに示される。次に、プロセッサが、データおよび命令を本発明と一致して操作する。図28の実施例では、データはコンピュータ自体のメモリ、または外部メモリの何れかの内部に記憶される。本発明は単一プロセッサ上で実施されることが現在は好ましいが、本システムが例えば、インターネットまたは他のネットワークシステムによりリンクされたコンピュータを含むコンピューティング環境の1または複数のコンピュータ上で利用されることは本発明の範囲である。特定のアプリケーションに対して、ソフトウェア、ハードウェアプロセッサ、およびファームウェアを用いて本発明を利用することが記載される。図29は、特に、セキュリティ、ライセンスキー管理、およびプーリング機能を含む3つの機能を有するファームウェアデバイスを示す。ファームウェアを使用する他の実施例は、他の機能をファームウェア部分で実施する。そのようなファームウェア/ハードウェア/ソフトウェアシステムでは、関連するソフトウェアを有するKnOSプロセッサは特定の機能に割り当てられ、一方、他の機能はファームウェアにより実施される。複数の実施例では、ファームウェアおよびプロセッサの両方が、種々のアプリケーションでデータを記憶装置または、デバイスに読み書きできる。図29は3つの現在の好ましい機能をファームウェアブロック図で示すが、他の実施例が本発明の様相と異なるファームウェアプロセッシングを有することも理解できる。説明のために、以下の用語が適用される:アプリケーション:特定の機能を実行するために使用される完全に自己完結型のプログラム。データインスタンス:任意の区別可能なデータ、情報、または知識。例えば、任意のデータ、情報、または知識例えば、任意の属性、アイテム、決定要素、キー、テーブル、列、行、フィールド、コンテナ、リポジトリ、環境、クラス型、モデル、関数、方法、オペレーション、関係、表示要素、クェリ、データモデル、ビュー、リポート、ユーザディスプレイスクリーン、データ型、ファイル型、アイテムパス、ファイル名、コンピュータ名、UPCコード、URL、ユーザ、接続、ステータス、品質、クラシファイア、ワード、センテンス、パラグラフ、ページ、チャプタ、ボリューム、オブジェクト、パーティション、セクタ、またはユーザが区別可能な参照。アトミック:その基本的な性質を破壊することなく定義によって分割できないもの。基本的なデータ構造:データ記憶または、データ表現パラダイムの最小の構造的構成要素。アイテム:基本的なデータ構造に基づくKnOSデータベースの基本ユニットで、アイテムは自己参照ベクトルキー、データインスタンス、および他の関連するアイテムを参照するベクトルキーセットをカプセル化する。ベクトルキー:アイテムへの多次元な特有の参照。ベクトルキーセット:ベクトルキーの配列であって、アイテムの内部にカプセル化され、参照アイテムとベクトルキーセットのベクトルキーに参照される全てのアイテムの間の特定タイプの関連を示す。論理アドレス:アイテムの抽象的ロケーションであって、実際の物理的ロケーションとは独立している。論理インデックス:実際の物理的ロケーションとは対照的にアイテムの抽象的ロケーションを直接的に参照するトークンまたは、値。KnOSの様相の中には、既存のデータ管理パラダイムおよび、技術と一見類似しているものもあるが、KnOS設計はデータ管理における完全に新規の発明である。KnOSは完全に対称なコンピューティングフレームワークであり、全ての値、関係、構造、およびコンテナを含み、全てのKnOSオペレーションは、これらの対称な特性上で行われる単純なブール関数である。フォームおよび関数の100対称性を用いて、KnOSはネイティブな大規模並列ベクトルマシンとして動作できる。KnOSは、KnOSインプリメンテーション全体にわたり一般に認識された形式に基づくセルラ細分性のベクトル化された値の表示を使用する。これは、独立に生成された機能的アプリケーションがアプリオリな取り決めまたは、構造的/スキーマ知識なしに情報を交換できることを意味する。完全に逆転した設計および最小の構造的競合を用いて、KnOSはリアルタイム更新および複合クェリの両方を、単一データコピー上において、最善のDWH製品よりも高い本来のプロセッシング効率を有する任意のコンピューティング規模で実行できる。KnOSのコア構造はバイナリ連想構造なので、連想データベース管理システムまたは、ADBMSと呼ばれる。本発明のキーとなる差別化要因は、データインスタンス中心アーキテクチャに基づくことであり、データインスタンスは一般にアトミック即ち、ユーザの観点からの定義により分割できない、例えば、データベースのテーブルのフィールドのデータであり、各データインスタンスは全連想の中心にあり、データインスタンスをカプセル化するベース構造、共通の基本的なデータ構造はフォームおよび関数において同一であり、独立したアプリケーションであって、また、他の全ての直接的に関連する独立にカプセル化されたデータインスタンスへのカプセル化された参照を含む。カプセル化された参照は、各々の、および全ての関連するデータインスタンス両方に対して特有の識別子であり、また、各データインスタンスの抽象化されたロケーションを完全に符号化する論理インデックスであり、任意のデータインスタンスを同じ参照キーを使用して識別および配置することの両方を可能にする。データインスタンスに対して、エンティティをカプセル化することはアイテムと呼ばれる。アイテムは、データインスタンス、およびデータインスタンスと他の全ての関連するデータインスタンスの間の連想を定義する全ての参照をカプセル化する。アイテムは基本的なデータ構造に基づき、ベクトルキーにより識別され、ベクトルキーはKnOSシステムの各アイテムを一意に識別する多次元参照である。図27のKnOS対称性に示すように、KnOSは最初の全面的に対称な企業コンピューティングパラダイムである。KnOSに対して、全ての値は他の全ての値と正確に類似し、全ての関係は他の全ての関係と正確に類似し、および全ての構造は他の全ての構造と正確に類似する。セルラ細分性と組み合わされるとき、コンピューティングモデルにおけるこの基本的な対称性は、作業負荷を容易に細分し、オペレーションを並列廃棄しながら実行するマルチプロセッサを可能にする。例えば、KnOSは、リレーショナル結合と同等の動作を有さず、必要としない。KnOSは、全プロセッシングを、完全にベクトル化された対称な構造上での最適化された2分木または、等価物検索を用いて行う。セルラ細分性、基本的な対称性、およびベクトル表現の一般的使用は、プロセッサ効率を理論的限界まで最大化する。他の事柄の中で、これは、プロセッサ性能の向上がKnOS性能の比例する向上をもたらすことを意味する。これは、任意のRDBMSまたは、任意のDWHアプリケーションについては当てはまらない。KnOS設計は、リレーショナルモデルに内在する問題の殆どを解決する。値対称性-任意のアトミックデータ値即ち、データインスタンス、例えばWhiteBeans9855がKnOSADBMSへ最初に挿入されるときはいつも、ベクトルキーとして知られるベクトル形式の大域的に特有の対称な参照値と一緒に登録される。その好ましい実施例では、KnOSベクトルキーは、そこに埋め込まれたロケーションの4つの次元を有する。それらは環境、リポジトリ、コンテキスト、およびアイテムと呼ばれ、ここではERCIと表される。もしWhiteBeansデータインスタンスがStockコンテキストへ広域的環境ドメインのManhattanSouthリポジトリにおいて挿入されたら、WhiteBeansはKnOSへベクトルキーERCI0613と一緒に登録される。ベクトルキーは、4次元的に特有の32ビットバイナリ整数の対称なセットとして各々が4ワードの個別ブロックで表現される。この16バイトのベクトルキーは、各アイテムに対するKnOSの大域的に特有の識別子である。特有の対称なコンパクトな値表現を提供することに加えて、KnOSベクトルキーは、情報を配置するために使用できる。データインスタンスWhiteBeansをカプセル化するアイテム0613は、コンピューティング環境0の第6のリポジトリの第1のコンテキストの第3のアイテムとして見出すことが出来る。最初にロードされるとき、全ての管理されたデータ値はこの方法で登録される。KnOSADBMSによる任意のASCII値の全ての他の参照または、使用は、これらのプロキシベクトルキーだけを参照する。図23の値対称性に示されるように、この設計特性は、KnOSの値対称性を確立する。関係対称性-全ての関係はKnOSに1または複数のバイナリセグメントとして記録され、各セグメントは2つのアイテムの間の本来的な双方向関連である。デフォルトとして、KnOS環境はペアの双方向一貫性を自動的に維持する。もしアイテムAがアイテムBを指したら、アイテムBはアイテムAを常に指す。KnOS連想は本来的に命名されないが、その代わり、値に基づき、効率を向上させるために分類できる意味論的分類は、KnOS調整技術である。KnOSアイテム意味論的過負荷を被り、アプリケーションが連想コンテキストの中で識別できるときはいつも、KnOSが種々の連想をコンテキストにより記憶する。これは正しい連想を識別するために必要なI/Oを減少させ、正しい連想は性能を向上させる。バイナリ連想の双方向ペアを使用して関係を記憶し検索するための技術は、完全に対称である。図24関係対称性は、もしベクトルキー0613によりWhiteBeansと識別されたStockアイテムが、ベクトルキー0623により1345と識別されたPriceアイテムに関連したら、StockおよびPriceの関係はWhiteBeansispriceof1345として本来的に対称なであることを示す。もしStockテーブルのPrice列が第2のインデックスを有するなら、リレーショナルモデルのタップルとして表現される同じ関連は対称なだけであることを銘記する。加えて、全てのKnOS関係が連想の内部、および全体の両方で対称に表現され、リレーショナルモデルの関係がタップル、および外部キーまたは、FKの両方を用いて表現され、外部キーまたは、FKは内部および全体表現の両方で非対称である。構造的対称性-バイナリ連想の各双方向ペアのターゲットベクトルキーは、サブジェクトデータインスタンスにより完全にカプセル化されて記憶される。もしWhiteBeansサブジェクトが1345ターゲットの値段を有する関係なら、ターゲットの合計金額を保持するアイテムがKnOSにERCI0623として登録される。サブジェクトアイテム0613WhiteBeansは、1345に対してターゲットアイテム0623によりカプセル化され、逆の場合も同様である。図25構造的対称性-KnOSアイテムに示されるように、各アイテムに対するカプセル化された参照のこれらの型に分類されるセットは1次元配列の順に記憶され、コンテキスト型によりベクトルキーセットVKセットと呼ばれる。全てのアイテムは、同じ完全に対称なデータベース構造-a自己参照ベクトルキー、bデータインスタンス、cVKセットとして表現される関係、およびdオプションとして1または複数のアイテム埋込要素IEEを有する。また、図26構造的対称性-KnOSコンテキストに示されるように、全てのカプセル化されたターゲット参照を有するKnOSアイテム構造も型により分類され、分類されたコンテキスト例えば、1つのコンテキストではStock、および他のコンテキストではPriceに記憶される。各コンテキストは他の全てのKnOSコンテキストと同じ構造を有し、これはKnOSコンテキストが完全であることを意味する。従来技術のシステムと比較して、KnOSシステムの多くの長所が存在する。これらの差異および長所が、以下に要約される。以下が、本発明の実施例の長所および目的を概説する。COTSアプリケーション:KnOSアイテムはセルラであり、KnOSコンテキストは完全に独立して100対称なので、KnOSデータベースはアプリケーション依存的ではない。この独立性は、考えられる最も広いスケールで持続する。企業リソース計画アプリケーションのKnOSスキーマは、地理情報システムと同じ形式および構造を有する。KnOSコンテキストは、他の任意のコンテキストの構造への影響なしに、およびソフトウェアへの予測不能なまたは連鎖的な影響なしに組み込みまたは排除できる。どの様な型のアプリケーションが実施されているかに関係なく、KnOSデータベースは正確に同じ方法で記憶され、アクセスされ、処理される。アプリケーションは、一度にローカルで最も利用可能な知識だけを用いて1つのコンテキストを構築できる。いったん定義されたら、各コンテキストは、そのコンテキストが拡張されるときに、その構造を決して変えることなく更新できる。COTSソフトウェアアプリケーションは1つのまたは、多くの産業界モデルに対して準備され、場合場合によって、RDBMSと関連するCOTSアプリケーション問題に基づくことなく実施される。非フローズン要求ベースライン:KnOSはアイテム毎に、コンテキスト毎に、およびリポジトリ毎に、迅速なアプリケーション開発または、結合アプリケーション開発技術を使用して実施できる。開発を開始してソフトウェア機能を提供するに当たり、KnOS設計の長所により、開発者は値の形式、関係の特性、データベースの全体構造、またはアプリケーションの設計でさえ理解する必要がない。KnOSの100対称なセルラ技術は、開発のために非フローズン要求ベースラインを必要とする。変化に対する非抵抗:インプリメンテーションのための非フローズンベースライン要求を踏まえて、KnOSの柔軟なインクリメンタル特性は、アプリケーションが局部的条件を越える影響を与えることなく局部的変化に対して連続的に調整できることを暗示する。例えば、テーブル列の等価物は、アプリケーションが走っている間に影響なしに追加または削除できる。構造的再編成に対する不必要性:KnOSの潜在的データリポジトリは、時間が経つにつれて劣化するテーブル構造では編成されない。KnOSの内部の挿入、編集、および削除作業は、KnOSオペレーションの効率に強い影響をもたない。KnOSコンテキストの内部のアイテムは、本来的に順次的、またはクラスタ依存的ではない。KnOSベクトルキーは完全であり、シークエンス依存的ではない。従って、KnOSインプリメンテーションは、効率を向上させるためにリロードまたは再編成する必要は決してない。完全に正規化する機能:完全正規化は、データベース管理の非常に優れた方法である。何故ならば、他の事柄の中で、更新し保守しなければならないデータの量を減らす一方で、更新例外および同期エラーを除去するからである。逆に、リレーショナルモデルの性能は、正規化の程度と反比例して劣化する。構造が正規化されるほど、RDBMSの性能は悪くなる。対照的に、KnOS設計の完全対称性は、性能が正規化の程度と直接的に比例することを意味する。完全に正規化されるとき、KnOSADBMSインプリメンテーションは最高性能を発揮する。また、リレーショナルモデルのカノニカルフォームは、非キー属性だけの値冗長性を非常に低いまたは、非常に高い基数を用いて除去する。しかし、高度に正規化されたテーブル構造値に基づく関係は、値冗長性を除去しない。ASCII形式のPK値は、リレーショナルモデルを通して繰り返される。何故ならば、値に基づく外部キーが、関係を記録するために使用されるからである。次元独立性-基本的セキュリティ:KnOSは、次元独立性をセルラ細分性から引き継ぐ。テーブルセルのKnOS等価物は、ゼロ、ゼロ、1、または多くの値0,1,M基数を有する。KnOSデータモデルはn次元であり、n次元は、アプリケーションの問題例えば、基本的セキュリティとなる任意の次元が、必要性に応じた最善の方法で適所でモデル化されることを意味する。アプリケーションの間のインターフェース:KnOSコンテキストは細分性においてセルラであり全面的に対称なので、種々のインプリメンテーションがアプリオリな取り決めを種々のリレーションの構造に対して有するか有さないかに関係なく、KnOSコンテキストはインプリメンテーションからインプリメンテーションへの類似性を比較できる。インターフェースする2つのKnOSアプリケーションインプリメンテーションに対して、類似の関連情報を用いてコンテキストを相互参照する必要があるだけである。アプリケーションまたは、サイトの各関連において、KnOSはこれらコンテキスト相互参照を維持できる。アプリケーションがこれら相互参照されたアイテムの1つに反するトランザクションを発行するときはいつも、KnOSは自動的に任意のベクトルキーを変換し、トランザクションをターゲットサイトに対抗して発行し、受信すると直ぐに応答を変換する。この方法で、KnOSアプリケーションはターゲットサイトのADDSの予備的知識なしにデータを読むことが出る。縦覧式の情報内容にアクセスして理解するために、ADDSの全体的複雑さが理解されなければならないので、KnOSを用いて、ターゲットアプリケーションまたは、サイトの属性は、複雑なリレーションで束縛される。複雑な相互関係をモデル化する機能:KnOSはリレーショナルモデルと比較して実質的に向上した関係コンテキストを有する。まだ値に基づくデータモデルであるが、KnOSは意味論的バイナリデータモデルを用いて1:1にマップされる図24関係対称性を参照。各関連は明白には命名されないが、KnOSのバイナリ連想は次元に関しては完全に類別でき、ベースコンテキストに従属する別々の命名されたタグセットへ分離できる。経験は、4つのカプセル化された関連次元parentchildlinkおよびrelatedのKnOSの好ましい実施例が、所定のレベルの性能効率を達成するのに十分な意味論的コンテキストを提供することを示す。KnOSのこれら特性は、処理能力性能を向上させる意味論的コンテキストの長所を取ることを可能にする。好ましい実施例ではないが、KnOSは、SBDMに含まれる任意の意味論を失うことなく、意味論的バイナリデータモデルをサポートするように容易に拡張できる。KnOSは、関係の分類のための2つの広い選択カプセル化、およびセグメント化を提供する。カプセル化された関係は、アイテムの従って、カプセル化されたコンテキストの内部に配置される。セグメント化された関係は、基になるコンテキストとアイテム毎に適合する別々の従属タグセットコンテキストに配置される。カプセル化とカプセル化の区別は、性能効率の単純な1つである。何れのカテゴリでも、関係は命名できる。タグセットは命名されるので、タグセットを有する意味論的コンテキストの損失はない。次元カプセル化は、単に連想次元を更に追加することによる命名された正確な意味論的コンテキストによる分類である。OLTPおよびDWHパラダイムの解決:コンピューティングパラダイムをテーブルレベルからセルラレベルへ変換することにより、KnOSはリレーショナルモデルの本来の競合の多くを除去する。KnOSは、行および列構造のカプセル化効率を、テーブルの非対称な特性を損なうことなく使用する。その結果、KnOSは、テーブルの非対称な構造のアプリケーションに依存する特性を損なうことなくテーブル表現を配置する能力を有する。KnOSは、リレーショナル結合に関連する非効率なしに、完全正規化に関連する効率および精度を得た。KnOSは本来的に完全逆転関係が対称的なので、OLTPおよび複合クェリの両方を、単一のコンピューティングパラダイム、およびデータベースコピー上でサポートできる。KnOSは、全ての関連する利点を有するOLTPおよびDWHコンピューティングパラダイムを再結合される。参照一貫性の解決:相互参照テーブルに基づくデータは、リレーショナルモデルにおける巨大な挑戦であり、進化するにつれて、システムの複雑さを管理するために更に多くの人工的なキーおよびテーブルの連続的追加を必要とする。複雑で非対称なシステムを複製されたキーで更新することは、特定キーの全インスタンスへの直接参照が存在しないので、更新の不完全さによる矛盾をもたらすことが多い。以下は値、関係、および構造的表現のためのKnOSの対称なフレームワークの短い議論であり、リレーショナルモデルに関連するこの問題および他の問題を克服する。ここで参照される図22-図26は、図1リレーショナルモデルの実施例に関係する。KnOSに関連する追加の長所が存在する。例えば、KnOSにより利用されるオープンディスク形式は、理論的可能性として本来的にセキュアである。これは、a殆どのデータベース値がプロキシである、b物的接近により暗示される関連が存在しないからである。KnOSディスク形式は、余白、またはASCIIビットパターンの何れかにより定期的に割り込まれるバイナリ整数の隣接する文字列の全体から成る。ASCIIビットパターンは、KnOSを走らせることにより128ビット暗号化を用いて任意の永続的なASCIIデータインスタンス、および任意の埋め込まれたASCII値上で容易に隠蔽でき、これは最小の性能ペナルティで出来る。いったんそれが遂行されたら、ディスク上のKnOSデータ表現はアプリケーション自体の他によっては本来的に判読不能である。もし、好ましい実施例のように、データベースの正確な意味論的コンテキストが、データベース中ではなくアプリケーション中で維持されるなら、KnOSの未加工データ形式からのコンテンツを識別する僅かなチャンスが本質的に除去される。意味論的ローディングの代わりにコンテキスト的分類を即ち、VKセットは分類されるが、各VKセットの正確な意味論的コンテキストはデータベースに記録されない、および128ビット暗号化をASCII表示で用いることにより、ディスク上のKnOSデータ形式は、全ての実用的目的に対して、一般配列である。KnOSは、任意の意味論的データモデルを押しのけ、または拡張しようとはしない。むしろ、KnOSはコンテキストにおいてバイナリデータモデルに類似する更に柔軟な連想コンピューティングフレームワークを提供し、任意のおよび全ての企業データモデルを実施する。更に、KnOSは意味論的コンテキスト分類を最大限使用して、最良の処理能力効率を所定の企業モデル上で達成する。即ち、KnOSの追加の意味論を好ましい実施例の範囲を超えて収集することは、コンピューティングの全コストを増加させ、本来のセキュリティを減少させそうである。KnOSは、更に広い連想DBMSを有する全RDBMSと取って代わろうとする。用語連想は、KnOSはリレーションおよびFK実施例のセット構造に限定されず、リレーショナルモデルのように、むしろ更に強力な意味論的データモデルにより定義される関係コンテキストの全範囲を可能にすることを記載しようとする。セルラ細分性、およびフォームおよび関数の100対称性により、KnOS設計はデータベース管理の新しいベンチマークであり、現在の全ての値に基づくコンピューティングパラダイムに取って代わるセルラコンピューティングパラダイムである。[図面の詳細な説明]以下は各図面の更に詳細な説明、種々の図面の説明である。図1リレーショナルモデルは、単一の主キーPK属性がStockである主リレーションStock、およびPKが2つの外部キーFK属性の組合せである連想リレーションStockOrders即ち、StockリレーションからのStock、およびOrderリレーションからのOrderを示す。また、図1は、如何にしてリレーショナルモデルが射影、選択、および結合してサンプルクェリ全stockorderのwhitebeansの総額はいくらかに答えるかを示す。図2主リレーションの同化は、如何にしてリレーショナルモデルの主リレーションがKnOSに同化されるかを示す。Stock主リレーションのタップルは、PintoBeansKidneyBeansWhiteBeansおよびWaxBeansと命名される。Stockコンテキストは、行関係を記録するために使用されるKnOSコンテキストの実施例である。主リレーションの他の全ての列は1つの列として各KnOSコンテキストに同化され、この場合、Stockに対するコンテキスト、およびPriceに対するコンテキスト列に類似したコンテキストである。図3連想リレーションの同化は図2に示されるプロセスを示すが、連想リレーション、またはリレーションのPKが他のリレーションからのFKとして移動するリレーションは別にする。各リレーショナル列に対する1つのKnOSコンテキストStockOrderリレーションのタップルを表現するための1つのKnOSコンテキストが存在する。図4行および列のKnOSコンテキストへの射影は、リレーションを図1からKnOSコンテキストへ変換する第1のステップを示す。KnOSコンテキストは1つの連想リレーションStockOrderの行に対して創出され、およびthen1つのKnOSコンテキストは両方のリレーションの各列に対して創出され、StockPriceOrderおよびQtyに対する追加のKnOSコンテキストをもたらす。図5KnOSコンテキストへの関係の同化は、図1に示されるリレーショナルモデル実施例の全関係のKnOSモデルへの同化を示す。図6意味論的バイナリデータモデルは、図1に示されるリレーショナルモデルのための古典的な意味論的バイナリデータモデルを示す。1つのKnOSコンテキストが意味論的バイナリデータモデルの各ノードに対して存在する点で、KnOSに類似している。双方向関係の各々は命名され、関連のインスタンス即ち、多値が左上に示される。図7バイナリ連想をKnOSコンテキストで表現するは、図6に示される意味論的バイナリデータモデルの単一セグメントを示す。実施例は、StockエンティティとPriceエンティティの関係を示す。関係の各要素は、Stockエンティティの1つの値例えば、PintoBeansをPriceエンティティからの適合する値と関連付ける。意味論的バイナリデータモデル記述は非対称であり、一方、KnOS記述は対称である。図8データ表示の比較は、3つの全ての表示リレーショナルモデル、意味論的バイナリデータモデル、およびKnOSで示された図1のリレーショナルモデル実施例からの未加工データを示す。下が、リレーショナルモデルからのADDSである。左が、意味論的バイナリデータモデルとして表現された同じデータベースである。右上が、正確なコンテキストはVKセットに示されていないが同じ未加工データのKnOS表現である。KnOSコンテキストは、バイナリデータ構造およびテーブル構造の両方からのデータを表現できる。図9アプリケーション独立性は、何故KnOSコンテキストが独立したアプリケーションであるかを示す。新しい属性をStockリレーション新しい列に追加することは、リレーショナルモデルのStockエンティティの物理的構造を変える。KnOSコンテキストデータアーキテクチャを用いて、同じ変更は更にVKセットをStockコンテキストへ単純に追加し、アイテムまたは、コンテキストの構造は変えない。アイテムは、Qty属性関連が追加される前後で同じ構造を有する即ち、ベクトルキーデータインスタンス-VKセット。図10KnOSオペレーションは、如何にしてKnOSがコアオペレーションを参照されたフェッチを用いて行うかを示す。この実施例は、図1のリレーショナルモデルで呈示された問題と同じである。KnOSは、1どのstockorderがwhitebeansのためのものかを決定する。Stockコンテナからのアイテム0613データインスタンスWhiteBeansをフェッチする。2アイテム0613からStockOrderコンテナ即ち、フォーム063Xのベクトルキーへの任意のVKセット参照を抽出する即ち、06310635。3関連する量を決定する。StockOrderコンテナからのアイテム06310635をフェッチし、Qtyコンテナ065Xへの任意のVKセット参照を抽出する。答は各々06510653である。06510653をQtyコンテナからフェッチして、答え1および3データインスタンスを各々得る。4whitebeansの価格を決定する。アイテム0613データインスタンスWhiteBeansからPriceコンテナへのVKセット参照即ち、フォーム062Xのベクトルキーを抽出する即ち、0623。アイテム0623をPriceコンテナからフェッチして、答え1345データインスタンスを得る。5KnOSの結果は拡張されて合計され、5380を得る。フェッチアイテムERCIは参照されたフェッチである。何故ならば、ベクトルキーERCIは、特有の参照およびKnOS論理アドレスの両方であるからである。図11プーリングの実施例は、如何にしてKnOSが質問PintoBeansのためのどのStockOrderがQty関係であり、関係はKnOSが完全逆転したデータモデルであることを意味する。KnOSは、アトミックデータインスタンスを、連続的にカプセル化されたコンテキストに、型分類によって、および各データインスタンスのためのKnOSが参照を記憶する記憶機構の内部に、ベクトルキー形式で、そのデータインスタンスに関連する全ての連想に対して記憶する。KnOS用語では、類似のコンテキストの特有のカプセル化されたデータインスタンス値は、アイテムと呼ばれる。アイテムは型コンテキストにより分類され、コンテキストでカプセル化される。コンテキストはリポジトリによりカプセル化され、リポジトリは環境によりカプセル化される。データインスタンスの間の全関係は、複雑ではあるが、2つのアイテムの間のバイナリ連想にカプセル化される。次に、連想は、VKセットに編成し関連するアイテムの内部でカプセル化することによって、意味論的または、他の概念的コンテキストにより型分類される。簡単に言うと、環境のカプセル化されたメンバはリポジトリであり、リポジトリのカプセル化されたメンバはコンテキストであり、コンテキストのカプセル化されたメンバはアイテムであり、アイテムのカプセル化されたメンバは他のアイテムを有する連想の分類されたセットであり、他のアイテムはベクトルキーVKとして表され、意味論的または、他のコンテキストによりVKセットに分類される。この基本的な編成は、KnOSが効果的にデータ値を関係に関連付けることを可能にする。細分性:また、如何にしてデータモデルが編成されるか即ち、データ値または関係の何れであるかも、データモデルの細分性を決定する。細分性は、データモデルが別々にアクセス可能な構成要素を含む範囲である。別々にアクセス可能な構成要素が多いほど、細分性が大きくなる。細分性が大きいほど、データモデルが更に柔軟になる。データモデルの細分性は、独立に確立できない。データモデルの細分性は、主要な編成規則のサブジェクト即ち、オブジェクトに基づいて単独で決定される。もしモデルが規則データ値により編成されるなら、データモデルの細分性は関係の最小要素サブジェクトである。リレーショナルモデルに対して、関係の最小要素はリレーショナルタップル即ち、リレーションの1インスタンス、テーブルの1行である。さもなければ、モデルは転置規則関係により編成され、データモデルの細分性はデータ値の最小要素である。データ値は、リレーショナルモデルの特有のゼロでない各セル値に類似する。この理由のために、リレーショナルモデルに対して逆転したモデルは、KnOSのように、セルラ細分性を有するものとして記述されるが、リレーショナルモデルは、行レベル細分性を有する。KnOSは、リレーショナルテーブルのセルラ値の特有の各インスタンスをアイテムと呼ばれる独立した概念として扱う。KnOSアイテムはKnOS設計の基礎なので、KnOSはリレーショナルデータをセルラレベルで表現できることを意味する。KnOSは、セルラ細分性を有するものとして適切に特徴付けられる。換言すれば、行によって情報を読み書きするリレーショナルモデルとは異なり、KnOSは特有のセルラ値によって所定の各コンテキストの内部で情報を読み書きする。各KnOSアイテムはその内部でカプセル化され、他の全ての関連する概念アイテムへの特定の参照は、その特定の行の全セルラ値、その特定のセルラ値を有するテーブルの他の全てのセル、およびそれらの行の他の全ての関連する概念、等を含む。KnOSにデータ値または、データ値の記述を提供するとき、KnOSの編成規則がそれらのデータ値に関連する全関係を提供できるという点で、これは編成規則関係を満足させる。要約すると、KnOSはデータインスタンス中心であり、リレーショナルモデルは関係中心である。要約すると、リレーショナルモデルの細分性は、タップルテーブルの行である。もしタップルをリレーショナルモデルに明らかにすることが出来たら、リレーショナルモデルはそのタップルに関連するまたは、含まれる全てのデータ値を戻すことが出来る。KnOSの細分性は所定のコンテキストのための特有の各データ値であり、所定のコンテキストは各々が特有の区別可能な概念または、アイテムであり、アトミックである。もし単一の特有のデータ値アイテムをKnOSモデルに明らかにすることが出来たら、直接的に関連する全てのアイテムをそのアイテムに戻すことが出来る。KnOSをリレーショナルモデルと比較することは便利である。本当に、任意のリレーショナルモデルは、最初に完全に正規化することによりKnOS表現へ完全に同化でき、全ての特有のデータ値をテーブルの内部でバイナリ連想として行×列オリエンテーションに基づいて分類する。しかし、転置は真ではない。リレーショナルモデルデータベースは常にKnOSモデルで完全に表現できるが、KnOSデータベースはリレーショナルモデルにより常に表現できるとは限らない。また、KnOSと比較されるとき、同じ記述が階層的なモデルおよびネットワークモデルにも当てはまる。KnOSは、データモデルに基づく任意のレコードセットまたは、テーブルよりも更に柔軟なデータモデル化パラダイムである。単純にリレーショナルに表現できないKnOS企業モデルを構築することが可能である。従って、リレーショナルモデルに関連するKnOSを考慮することは便利であるが、この限定された方法で定義することはKnOS発明に対して有害である。リレーショナルモデルとは違って、KnOSのアイテムは、ユーザにより区別できる任意レベルの抽象化で定義できる。例えば、任意のデータインスタンス即ち、任意のデータ情報、または区別可能な知識は、単一のKnOSアイテムである。それは特性、決定要素、キー、テーブル、列、行、クラス型、モデル、プログラム、関数、方法、オペレーション、表示要素、イメージ、クェリ、データモデル、ビュー、リポート、ユーザディスプレイスクリーン、データ型、ファイル型、アイテムパス、ファイル名、テーブル名、コンピュータ名、データベース、UPCコード、シリアル番号、部品番号、URL、ユーザ、プロトコル、接続、メッセージ、ステータス、品質、クラシファイア、ワード、センテンス、パラグラフ、ページ、チャプタ、ボリューム、オブジェクト、パーティション、セクタ、BLOB、CLOB、ポインタ、または参照でもよい。KnOSアイテムは、ユーザが識別できる区別可能な任意の概念でよい。要約すると、KnOSは無制限のn次元モデル化環境であり、リレーショナルモデルは折り畳まれた2次元表現である。もしリレーショナル表示だけが快適ならば、KnOSはユーザに容易に対応できる。KnOSデータモデルの細分性に関する決定は、実施者に残される。KnOSは、如何にしてデータが編成されるべきかという次元についての先入観をもたない。好ましい実施例では、KnOSは全面的に自己参照モデル化環境であり、インプリメンテーションに関連する全てがKnOSデータベースに適切な型のKnOSアイテムとして記憶されることを意味する。対称性この[本発明の詳細な記載]全体を通して、本文は対称性を参照し、a相互類似性、bフォームおよび配置の類似性、およびcサイズ、形状、および位置における対応を意味する。本明細書は、なぜ対称性がモデル化プロセスに対する重要な特徴なのかを詳しく述べない。モデルが対称であるほど、定義、変更、処理が更に単純で効率的であることを言えば十分である。また、モデル対称性は、プロセッシングにおける並列化に対して重要である。モデルが対称であるほど、更に容易に、および更に完全に並列処理できる、リレーショナルモデルは、関係の定義を対称性の解析を通してシークする。いったん分かれば、関係は対称性によって完全に特徴付けられる。類似の対称性を有するように後で決定された候補となる別個の任意の関係は、同じ関係に組み合わされる。次に、残りの特有の非対称に定義された関係は、正規形でリレーショナルモデルを構成する。従って、非対称な表現は、リレーショナルモデルにおける定義の主要な手段として使用される。正規形で適切に構成されるとき、リレーショナルモデルは100非対称である。他の事柄の中で、これは、データモデルが構成される前に全ての企業の関係が正しく理解されなければならないことを意味する。もしリレーショナルモデルの2つの別個の構成要素が後で対称または構造的に合同テーブルの同じ列に含まれることを意味するであると決定されたら、データモデルは2つの構成要素を組み合わせるように修正されなければならない。KnOSモデルは関係に基づかず、むしろ特有のデータ値に基づく。KnOS関係は2つのデータインスタンスの間のバイナリ連想のセグメントで構成されるものとして定義され、アイテムとしてカプセル化され、多次元ベクトルキーとして表現される。KnOSは最初の完全に対称なコンピューティングパラダイムとして特に設計され、対称な値、関係、および構造で構成される。KnOS対称性の議論は、値対称性から始める。値対称性ASCII値は全面的に非対称である。何故ならば、ASCII値はa相互類似性、bフォームおよび配置の類似性、およびcサイズ、形状、および位置における対応を欠くからである。全データ値、概念、等KnOSアイテムの大部分はASCII値によって表現され、主な例外はバイナリラージオブジェクトBLOBである。データ値がASCII形式で表現されるとき、色々な理由から記憶および処理が困難である。その結果、殆どのデータ保管DWHアプリケーションは、対称性およびコンパクト性をコンピューティングプロセスに注入しようとして、ビットマップ表示をASCII値の代わりに用いる。DWHはビットマップをローカライズされたベースで使用するが、KnOSは完全な値対称性を全般的スケールで有する。KnOSは、全てのアイテムのASCII値表現ここでは、データインスタンス、またはThOhTと呼ばれるを全面的に対称な多次元参照ここでは、ベクトルキーと呼ばれるに変換することにより、100値対称性をコンピューティングパラダイムに注入する。別々の各アイテムは特有のベクトルキーに割り当てられ、最初にKnOSコンピューティング環境に導入され、しかも、それ以降、ベクトルキー割当は決して交替、変更されず、他の任意のコンテキストで再使用されない。KnOSベクトルキーは、各データインスタンスに対して全面的に対称なプロキシである。換言すれば、1つのKnOSベクトルキーを他と比較するとき、アクティビティはa相互類似性、bフォームおよび配置の類似性、およびcサイズ、形状、および位置における対応を有する。この対称性は、図23値対称性に示される。任意の動作更新、またはクェリがKnOSで始まるときはいつも、最初のステップは常に、トランザクションでパラメータとして表される任意のデータインスタンスのベクトルキーを決定することである。もしKnOSに呈示される任意のデータインスタンスが新しければ、KnOSはもしクェリなら動作を拒否するか、またはもし更新ならa新しいデータインスタンスを特有のベクトルキーに割り当て、およびb新しいデータインスタンスをASCII辞書に追加するかの何れかである。次に、データインスタンスに対するKnOSベクトルキーは、コンピューティングオペレーションのためのKnOSにより排他的に使用される。事実上、KnOSは非対称なデータ値を入り口で変形し、それ以降、完全に対称なベクトルキーと一緒にプロキシとしてのみ機能する。KnOSの対称な参照は、モデルの各次元に特有のバイナリ整数の順序付きセットから成るベクトルキーという形をとる。本発明の一般的な実施例では、ベクトルキーは、環境、リポジトリ、コンテキスト、およびアイテムとして知られる4つの次元を有する。KnOSベクトルキーここではERCIと呼ばれることが多いは32ビット1ワード、4バイトの4つの別個のバイナリ整数から各々が成り、各バイナリ整数はその次元に特有である。所定のアプリケーションに対する参照次元の実際の数は、4より少ないか、または多い。4つの次元は、単純な好ましいインプリメンテーションである。複数の実施例では、32ビットワードの30ビットだけがベクトルキーとして使用され、2ビットは参照型識別されたシステムをマークするために残されるが、全ビット幅が必要とする実施例のために利用可能である。ワード幅はコンピューティング環境により定義され、従って、もし64ビットワード幅が利用可能なら、参照もそうであり得る。ベクトルキーは、アイテム参照に限定されない。また、ベクトルキーは、コンテナヘッダに同じERCI形式環境ヘッダE000リポジトリヘッダER00、およびコンテキストヘッダERC0で適用でき、CRNO形式でリポジトリディレクトリ、およびIRNO形式でコンテキストディレクトリの両方に適用できる。VKセットベクトルキーの配列は型により一定でなければならず、ERCI形式のベクトルキーはIRNO形式のベクトルキーと混合できない。関係対称性リレーショナルモデルでは、関係は2つの方法基本的なリレーション、または共有識別子値FKの1つで記録される。これら2つのアプローチは完全に異なり、対称性を全面的に欠く。定義により、2つのリレーションまたは、共有識別子値は類似していない。もし2つのリレーション、または2つの共有識別子が類似していたら、それらは組み合わされて1つになる。関係を記録するためのリレーショナルモデルの方法は、実際には識別力においてそれ自体を誇り、識別力は対称性を欠くと言われる。KnOSの基本的な編成規則関係はリレーショナルモデルに関して逆なので、KnOSは全関係が2つのおよび、2つだけのデータインスタンスを比較することを要求する。KnOSは、れらのバイナリ関係を連想と呼ぶ。また、任意のデータ値から付随的な関係へ行く組織的要求は、全バイナリ連想が本来的に双方向転置であることを意味する。図24関係対称性の実施例は、showsthat2つのデータインスタンスアイテムWhiteBeans、およびアイテム1345が互いに関連することを示す。特定の意味論的コンテキストは、aWhiteBeanshavepriceof1345、およびb1345ispriceofWhiteBeansである。何れの意味論的コンテキストも、基本的な編成規則関係で与えられたKnOSにアクセス可能でなければならない。連想の内部でビューされようと間でビューされようと、KnOSのバイナリ双方向関連は100対称である。KnOSが双方向関連を2つのアイテムの間に登録するとき、関連はa相互類似性、bフォームおよび配置の類似性、およびcサイズ、形状、および位置における対応を有する。図24に示される実施例の意味論的コンテキストの短い評価を行う点に価値がある。リレーショナルモデルもKnOSも、正確な2つの意味論的コンテキストを、それほど多くのワードでは記録しない即ち、havepriceofおよびispriceof。各モデルは、Priceが何とかして関係に含まれることだけを記録する。リレーショナルモデルは、Priceを列の名前属性として記録し、KnOSはPriceをコンテキストの名前として記録する。図24の左上に示される意味論的バイナリデータモデルは、各関係の意味論的コンテキスト全体を直接的に記録する。KnOSは関係の意味論的コンテキストを型の類似性によってマップし、従って意味論的コンテキストは、それらの次元のコンテキストの内部で連想を読むこと、およびコンテキストをカプセル化することによって直接的に推論できる。構造的対称性データモデルにおける対称性の最後の最も重要な次元は、構造的対称性である。構造的対称性は、如何にしてモデルの部分が記憶されるかに言及する。リレーショナルモデルの編成規則データ値は、データが関係によって記憶されることを意味する。関係をリレーショナルモデルで図示することの意味は非対称なので、データ記憶の構造は非対称である。KnOSの編成規則はデータ値関係によって駆動されるので、KnOSは構造的対称性を有することが出来る。実際には、図25構造的対称性-KnOSアイテムおよび図26構造的対称性-KnOSコンテキストに示されるように、KnOS記憶構造における抽象化の異なる各レベルは対称である。VKセットのように、アイテムコンテナの内部でカプセル化された関係は、構造的対称性を有する。各アイテムは、他の全てのアイテムと構造的に同じである。アイテムは型で分類され、コンテキストに記憶される。アイテムの各コンテキストは、アイテムの他の全てのコンテキストと構造的に同じである。実際には、KnOSコンテナの異なる型が異なる機能を果たすが、KnOSコンテナはコンテナ型全体にわたって構造的に対称である。アイテムコンテナ、およびコンテキストと呼ばれるKnOSコンテナは、構造的に対称である。同じ構造的対称性はリポジトリコンテナと一緒に存在し、環境コンテナも同様である。図27KnOS対称性は、KnOSモデルをどんなに見ても、KnOSモデルは完全に対称であることを示す。値、関係、または構造を考慮してもしなくても、これは真である。KnOSモデルの構造的対称性の内部では、コンテインメントの対称性も存在する。他の全てのDBMSでは、データ値はそれらのコンテナを参照しない。何故ならば、それらが単にスペースを占有し、位置をコンテナの中に有するからである。いったんコンテナから読み出したら即ち、テーブル、または木、データ値はそのコンテナを参照せず、従ってコンテキストは外部から維持されなければならない。データインスタンス読み取りの数が増えるほど、これは困難になる。KnOSのアイテムとしての全データインスタンスは、アイテムがベクトルキーを介する本来的な自己参照である点において、それらのコンテナコンテキストと対称な関係を有し、従って、それらのコンテナコンテキストの定義参照により、それら自体を呈示する。コンテキストは、アイテムをそれらの内部で常に参照する。加えて、実際のロケーションへのアイテムの論理的-物理的マッピングは、KnOSが実際のロケーションからアイテムが存在するところへの物理的-論理的マッピングを維持する点において対称である。ベクトルキーベクトルキーは、2つの別個の目的を有する。第1は、各々および全てのアイテムを識別する特有の識別子として作用することである。第2は、KnOSがアイテムを発見することを可能にするロケータキーまたは、論理インデックスとして作用することである。ベクトルキーを任意のアイテムへの全般的参照として使用することは、KnOSが連続的にカプセル化されたコンテナ参照をERCIにおいて好ましい実施例では、キーの要素として符号化し、それらの要素を連続的にカプセル化された各コンテナへの直接インデックスとして使用することを可能にする。ベクトルキーは識別子、および各アイテムに対するロケータとして作用するので、アイテムにおいてカプセル化された関連の任意の次元の任意のVKセットにおいて関連を指定するために直接的に使用される。本明細書全体を通して使用される用語次元は、2つの別個の事柄aアイテムの参照の次元、およびbアイテムの関係の次元を意味する。ベクトルキーは、本質的に、アイテムの参照の次元の内部で一意に配置される位置への論理インデックスである。また、ベクトルキーはアイテムを一意に識別するので、アイテムの間の関係を記録するためにも使用される。従って、1つの次元または、他のアイテムの参照のVKセットに分類されるとき、ベクトルキーは関連するアイテムを一意に識別し直接的に配置するために使用される。KnOS連想の分類は、関係次元を構成する。KnOSは、次元を折り畳まれたまたは、連続的にカプセル化されたと言われる。その親または、エンベロープコンテナの内部で各々が一意に番号を付けられるように、アイテムは一連の明快に境界を付けられたコンテナの内部に収容される。アイテムコンテナは、親コンテキストの内部で論理的に配置できる。アイテムのコンテキストはそのリポジトリコンテナの内部で論理的に配置でき、アイテムのリポジトリはその環境コンテナの内部で論理的に配置できる。ベクトルキーだけを用いて、特定のアイテムが配置されるまで次元から次元へ通過することが可能である。各アイテムコンテナは、その関係次元をカプセル化する。本発明の好ましい実施例では、バイナリ連想または関係も4つの次元parentchildlinkまたはrelatedに分類され、各アイテムコンテナの内部でカプセル化される。ここで、各次元の関連のバイナリ状態は、関連するアイテムを参照するベクトルキーの有無により各々表現される。ベクトルキーの存在は、関連する各アイテムをその次元で一意に識別し、KnOSに各アイテムを直接的に配置するための手段を提供する。従って、関係次元は、アイテム次元の内部で折り畳まれる。各環境は、常に自らの第1の参照である。全ての折り畳まれたアイテム次元が露出されたら、いったん所定の環境が入力される。図22コンピューティング環境の間の相互参照を参照のこと。一般的な実施例では、各環境は3つの主要な折り畳まれたアイテム次元RCおよびI、および1つの主要な外部次元Eを有する。ここで、一般にE1はその環境への自己参照である。一般に、E0はCreatorまたはLicenseMasterを参照し、他の環境は遭遇したものとして追加される。この方法で、全ての環境は、異なる他の環境へのE参照を有する。Eは論理的参照であり、従って、環境値例えば、2は、多分、異なるKnOS環境の異なる事柄を参照することを銘記するのは重要である。換言すれば、Eが何れかである特定の割り当てを有するマスタ環境リストは存在せず、リストは何らかの権限により維持されなければならない。これは、一般に参照可能なEの定義されたセットの割当を排除しない。例えば、E0はKnOSに対する中央ライセンス権限である。E411は、KnOSシステムに対するマスタ知識ベースである。E611は保守、または技術サポート、等に対するものである。実際には、KnOSは最初のnEをこれらの型のアプリケーションに対して予約する。折り畳まれた4つの次元ERCIに特有のカプセル化されたベクトルキーを有する各アイテムを用いて、全ての環境の全てのアイテムは、各アイテム自体のベクトルキーを有する全ての関連するアイテムを分類しカプセル化することにより、全ての環境の他の全てのアイテムに関連することが出来る。各環境の多次元参照スキームは、内部で完全に首尾一貫している即ち、その環境の内部の何れの他のアイテムが参照として使用しても、環境の内部の任意のアイテムに対するベクトルキーは特有である。特定のメモリアドレスまたは、特定の物理的ロケーションポインタではないことを理解することは重要である。各アイテムは他の全ての適用可能なアイテムに関連するコンテキストに配置されるが、配置は参照により行われ、参照はコンテキストの内部でカプセル化され、物理的に隣接する必要はない。アイテムは、論理的参照によってアドレス、または物理的ロケーションによってではない常に記憶されて検索される。従って、KnOSの必要条件を提供し最適に効率的である限り、何れの潜在的機構が実際にアイテムを記憶媒体に記憶するために使用されるかは必ずしも重要ではない。アイテムの記憶装置および検索に対する一般的な潜在的機構が、ここで記載される。好ましい記憶機構がKnOSの論理的レイヤおよび物理的レイヤの間の対称性を有し、論理的ロケーションシステムが物理的ロケータトークンをカプセル化し、物理的記憶システムが論理的ロケータトークンをカプセル化することを銘記する。任意のアイテムに関連するKnOSデータインスタンスは、所定のコンテキストのリレーショナル属性例えば、PersonDuaneNystromQty3StockWhiteBeansまたはPrice1345の単一インスタンスと類似する。コンテキストはリレーショナル属性例えば、PersonQtyStockPrice全体に類似し、値の全範囲を含む。換言すれば、KnOSコンテキストは、アイテムの所定の型の全てのアイテムを保持できる。ベクトルキーのリポジトリ次元は、コンテキストの集合である。それは、実世界ロケーション、特定のマシンの複雑さ、またはデータ例えば、領域、地域、または市例えば、NewYorkNYまたはLosAngelesCAリポジトリの他のユーザ/アプリケーションに依存する編成を参照する。ベクトルキーの環境次元はリポジトリの集合であり、リポジトリは、世界ビュー例えば、国家または大陸例えば、アメリカ合衆国、またはカナダ環境を表示するために使用できる。さらに詳細には、それは、リポジトリの収集を収容または仲介する実際の実世界コンピューティング環境を識別するために一般に使用される。実際のアプリケーションでは、特にこれらの次元はKnOSのアイテム次元だけを参照するので、4つの次元を有する参照は、任意のデータ管理問題を扱うのに十分である。関係モデル化の意味論的コンテキストは、KnOSの無制限の次元を以下に記載される連想の分類およびセグメント化を通して有する。図12多次元参照モデルは、多次元参照スキームの一般的なインスタンスを示す。ベクトルキー記号ERCIが示すように、ベクトルキーは、単純に連結された4つの別個の1ワードのバイナリ数字例えば、13815環境1リポジトリ38コンテキスト1およびアイテム5である。32ビットマシン1ワードに対して4バイトでは、ベクトルキーの4つの要素の各々が、一般に30ビットバイナリ整数即ち、2300から1073741824ベース10に拘束されるしかし、全32ビットが使用できる。従って、全ベクトルキーは、230×230×230×2302120個の異なるアイテムを参照または識別できる。多次元参照モデルは、広く拡張可能である。単一ロケーションで始め、第2、第3を等を追加することが可能である。後で、ロケーションは複数の環境に分割される。単一ロケーションに対して、0115が有効なベクトルキーであり、唯一のリポジトリのコンテキスト1の第5のアイテムを参照する。後で、もし第2のリポジトリが追加されたら、それはリポジトリ2になる。第1のリポジトリのデータに対して、何も変える必要はない。1つの環境/リポジトリからのデータは、アプリケーションによって、他の任意の環境または、リポジトリから混乱なしに読める。KnOSアイテム:KnOSアイテムは、アプリケーションとは独立した基本的なデータ構造に基づく。図13KnOSアイテムの構造は、アイテムの概念的および完全に形成された物理的表現の両方を示す。物理的表現は、右側に示される。アイテムは、可変数のワード32ビットマシンでは、各ワード32ビットまたは4バイトから成り、ここでは4ワード/行で示される。右側に示される行×列テーブル表現は厳密に説明目的であり、アイテムの実際のインプリメンテーションを表現しない。18行×4列構造は、実際には存在しない。図13に示されるDuaneLewellynNystromEsqアイテムは18×4=72ワードをもたないが、むしろ71ワードをもつ。行6の灰色セルは存在しない。実際には、アイテムは可変長レコードである。図13に示されるアイテムの行×列表現は、アイテム自体のベクトルキーおよび、関連するアイテムのベクトルキーを読むことを容易にすることを意図する。アイテム自体のベクトルキーまたは、アイテムのVKセットに関しては、ワードの4列がベクトルキーERCIの次元を表す。さもなければ、4列はアイテムに対する意味をもたない。アイテムの4ワードの第1の行は、図13のアイテムに対する主要な自己参照ベクトルキー13815である。12ワードから成る第2,第3,および第4の行がアイテムのマップを与え、如何にして可変長アイテムの残りを読むかを記述する。図13のアイテムマップは、DuaneLewellynNystromEsqと示されるように、アイテムのデータインスタンスが次の7ワードであることを述べる。また、各アイテムが所定のアイテムデータインスタンス、データ値、概念に対して定義された全ての連想の和を完全にカプセル化するように、各アイテムは、ベクトルキーセットと呼ばれる分類された次元付きのセットに配列された関連するアイテムの無制限の数のベクトルキーを連鎖してカプセル化する。単一のアイテムの内部の異なるVKセットは、異なる型または、分類の連想に対応し、一般に4つの主要な型がある。図13のアイテムマップは、第1に3つの各々が4ワードのparentベクトルキーのVKセットがあり、次に2つのchildベクトルキーのVKセットがあり、次に2つのlinkベクトルキーのVKセットがあり、2つのrelatedベクトルキーのVKセットが続くことを示す。parentchildlinkおよびrelatedがKnOSにより使用される関係意味論的コンテキストの4つの一般的な分類または、次元であり、ishasdoesおよびgoeswithの意味論的コンテキストを表しているよう見える。任意の数の他の意味論的コンテキストがいつでも追加でき、KnOSによって無制限に課される。もし所望するなら、追加的な関係する要素がアイテムに埋め込まれる。これらは、アイテム埋込要素または、IEEと呼ばれる。IEEEはデータ例えば、部品番号、住所、またはVKセットであり、他のアイテムを参照する。図13は、DuaneLewellynNystromEsqアイテムが埋め込まれた電話番号5148249949および住所3307BlakeLaneUnit47を有することを示す。また、埋込要素は別々のアイテムとしても表され、主要なVKセット次元の1つを通して、または単一ベクトルキーまたはVKセットの何れかとして埋込要素に生成された第2の次元を通して明白に参照される。埋込アイテムデータは任意である。もし人間についてのリポジトリに入力される殆どのクェリも人間の電話番号を要求し、どの独立したクェリも電話番号により行われないなら即ち、誰が電話番号5148249949を有するのか、これらの値を各人間アイテムに埋め込むことも納得できる。さもなければ、電話番号は右側にあるコンテキストである。例えば、もしリポジトリがクェリを電話番号によってサポートしなければならないとしたら、電話番号を埋め込むことは、全アイテムに含まれる全埋込アイテムもASCII辞書に追加されるまで次節を参照、相互参照され、従って、2分木検索によって識別可能かつアクセス可能なデータを通した完全なサーチ無しでは機能しない。KnOSのコンテナの各型はアプリケーションとは独立した基本的なデータ構造であり、その中では構造的に合同で、自己参照し、およびコンテンツをカプセル化し、KnOSを使用して構築された任意のアプリケーションから完全に独立している。最低レベルから最高レベルまでリストにしたKnOSコンテナに対して仮定した分類スキームは、アイテム、コンテキスト、リポジトリ、環境である。コンテキストはいくつかのアイテムを収容し、リポジトリはいくつかのコンテキストを収容し、環境はいくつかのリポジトリを収容する。用語コンテキストは特定の型のコンテナを参照し、即ち、コンテナはコンテキスト的定義または分類即ち、人、顧客、製品、会社、種、色、部品番号によりグループ化された全アイテムを論理的に収容することを銘記する。KnOSコンテキストおよびリポジトリ:図18の左半分コンテキストおよびアイテム構造は、アイテムのコンテキストを示す。図18の右側は、その様に含まれたアイテムの1つを示す。構造的に、アイテムおよびコンテキストの間に違いはない。アイテムはメンバを有し、メンバはベクトルキーのVKセットである。コンテキストは追加メンバを有し、追加メンバはアイテムである。コンテキストでは、たとえ同じ構造および同じ数のワード要素をもっていても、アイテムメンバのベクトルキーはリテラルERCIではない。定義によると、所定の数のコンテキストは、他の全てのメンバの同じコンテキスト、およびコンテキスト自体でさえ有するのと同一のERおよびC値を有する。従って、アイテムI値だけまたは、ベクトルキーの4つの要素の一番右が、コンテキストのアイテムメンバのベクトルキーで維持されるのに必要である。他の3次元即ち、ERおよびCへの供給は、物理的ロケータインデックス、バイト中のアイテムサイズ、ステータス、および状態フラグに対して使用される。全メンバのベクトルキーは記憶された順番でアイテムI値により維持でき、アイテムI値はコンテキストの任意の指定されたアイテムの迅速なルックアップを可能にする。また、コンテキストのこのメンバ情報の使用も、図160682を物理的媒体に配置に示される。図16のアイテム3は、コンテキストを示す。アイテム4および5は、コンテキストのメンバ2ペアに4ワードを示す。通常のERCIでは、Iは4番目の位置にある。ERおよびCはコンテキストの中に維持される必要がないので、コンテキストのメンバベクトルキーは、一番左の位置にあるIから始まる。これらのERCIはIRNOとしてより良く記述され、アイテム、相対、次、およびオフセットを意味する。左から右へ読むと、コンテキストのメンバエントリはアイテムの実際の数を与え、最後の2つの位置N,Oを参照するアイテムロケータディレクトリの相対位置が続き、ディスク上で遭遇する次のアイテムの数が続き、アイテムのデータインスタンスへのページオフセットが続く。類似の状況が、リポジトリコンテナと一緒に存在する。リポジトリの場合、メンバがコンテキストを記述し、コンテキストはベクトルキーがCRNOとしてより良く記述されることを意味し、コンテキスト、相対、次、およびオフセットを意味する。左から右へ読むと、リポジトリのメンバエントリはコンテキストの実際の数を与え、最後の2つの位置N,Oを参照するコンテキストロケータディレクトリの相対位置が続き、ディスク上で遭遇する次のコンテキストの数が続き、コンテキストのデータインスタンスへのページオフセットが続く。図17リポジトリ構造が、これを図示する。図16は、ERCI0682であるアイテムに対して、アイテム2へのコンテキストメンバベクトルキーはIRNO2367であり、コンテキスト8へのリポジトリメンバベクトルキーはCRNO8315であることを示す。ERCIIRNOまたはCRNOの何れでも、全てがベクトルキーであり、グループ化されるか分類されるときは、VKセットとして参照される。これは、KnOSのコアパワーを図示し、アイテムは、ディスク媒体に埋め込まれたアイテムのベクトルキー、および論理的-物理的ディレクトリだけを用いて配置できる。CRNO形式のVKセットは、ディスクリポジトリディレクトリである。IRNO形式のVKセットは、ディスクコンテキストディレクトリである。KnOSは、任意のアイテムを、そのERCIを最初にそのコンテキストのCRNOと、次にそのリポジトリのIRNOと比較することにより配置および検索できる。アイテムに対する配置およびフェッチプロセスの第1のステップは、正しい環境を配置することである。環境から、CRNO形式のリポジトリディレクトリはアクセス可能である。リポジトリディレクトリを使用して、KnOSはトランザクションこの場合には0682により参照されるERCIをCRNOと比較する。CRNO8315は、0682と一致する即ち、ERCIのCがCRNOのC値と一致するリポジトリメンバエントリである。この場合、リポジトリディレクトリエントリの5のO値は、親コンテキストを含むディスク媒体上のページに対するオフセットを与える。コンテキストディレクトリを使用して、KnOSはトランザクションこの場合には0682により参照されるERCIをIRNOと比較する。IRNO2367は、0682と一致する即ち、ERCIのIがIRNOのI値と一致するコンテキストメンバエントリである。この場合、コンテキストディレクトリエントリの7のOは、親アイテムを含むディスク媒体上のページに対するオフセットを与える。図17および図18は、論理的-物理的ディレクトリの上記要素を物理的-論理的ディレクトリからセグメント化する他のアクセス方法を図示する。ディスクロケーションのための物理的-論理的ディレクトリは、各リポジトリコンテナのVKセットに配置され、RAMロケーションのために、KnOS自体の環境コンテナに配置される。RAMおよびディスクロケータの両方のためのページIDオフセット参照は統合され、別々のオペレーティングシステムメモリおよびディスク管理サブシステムに対する必要性を除去する。ページIDによる全メモリ配置および配置解除は、KnOSにより管理される。物理的レイヤ読み出し/書き込みだけがハードウェアドライバにより操作され、ハードウェアドライバはページIDオフセットに割り込み、それらをRAMおよびディスクシステムの潜在的な物理的構造にマップする。コンテキスト名およびアイテムデータインスタンス:全KnOSコンテキストは、コンテキストのアイテムのコンテンツを記述し分類する名前を有する。同様に、コンテキストの各アイテムは特有のデータインスタンスを所定のコンテキストの内部で表現し、所定のコンテキストは、如何にしてユーザが各アイテムをコンテキストの内部で識別するかという意味で名前として可視化される。それらは識別のために使用されるので、コンテキストの中で各アイテムにより表現されるコンテキストの名前およびデータインスタンス値は、特有であるべきである。多くのコンテキストおよびカプセル化されたアイテムはユーザによって一意に命名できるが、出来ないものもある。名前付きと名前無し命名されないKnOS概念を説明する一番簡単な方法は、それをリレーショナルモデルと比較することである。データ3NFの正規化されたテーブルがKnOSによって同化されるとき、テーブルの各列がKnOSコンテキストにマップされる。次に、KnOSが1つのカプセル化されたアイテムが各コンテキストの内部で創出され、各コンテキストの名前各々特有の、列のゼロでないセル値であり、KnOSのデータインスタンスに対応する。これは、KnOSアイテムとして、テーブルの各列で見出される特有の各データ値を同化する。もしcolorがテーブルの列にあれば、colorはKnOSコンテキスト属性、または列の名前であり、種々のcolor自体pinkgreenlavenderがcolorコンテキストの内部で参照されるアイテムである即ち、greenは、colorコンテキストの特定のアイテムのデータインスタンスである。もしageがコンテキスト属性、または列ならば、age123nに帰する基数はageのデータインスタンスである即ち、14はageデータインスタンスである。列の特有の各データインスタンス即ち、個々のASCII値はデータインスタンスであり、各データインスタンスはベクトルキー参照を有するアイテムに関連する。図13KnOSアイテムの構造の実施例では、データインスタンスDuaneLewellynNystromEsqである。もし色brownが3NFテーブルの2つの異なる列で遭遇したら、2つの異なるデータインスタンスおよび2つの異なるアイテムが創出されたと考えられる各列に1つのbrownアイテム。2つの異なる名前を有すると思われる2つの列は、例えば、haircolorおよびeyecolorであり、haircolorおよびeyecolorは関係の2つの異なる意味論的コンテキストである。brownは、2つの非常に異なる独立したコンテキストで、個人の髪の毛の色、および個人の目の色として独立に個人に関連することを銘記する。KnOSは、これを別々のコンテキストとして同様に実施し、1つはHairColorおよび1つはEyeColorとして命名され、brownは各々におけるアイテムのデータインスタンスである。従って、創出されたコンテキストは、列のようなコンテキストであると考えられる。行連想をKnOSに記録するために、行を表現するためのKnOSコンテキストも必要である。もしユーザが行の値を3NFテーブルで命名できたら、一般にテーブルはテーブルのPKとして1属性列を有する主リレーションである。その様な場合、テーブルのPKを表現する1つのKnOSコンテキストは、テーブルに対する行プロキシである。もしリレーショナルモデルの主要なテーブルがPKとして機能する単一の列を有するなら、それは命名されたテーブルである。PK列の値は、テーブルの各行または、リレーションのタップルを一意に識別する。主要なテーブルがKnOSにより同化されるとき、テーブルのPK列はKnOSの行プロキシコンテキストになる。図2主リレーションの同化に示されるように、Stock主リレーションは、2つの列StockおよびPriceを有する。これらは、KnOSの内部に、StockおよびPriceと命名された2つのコンテキストとして同化される。StockはテーブルのPKまたは、行の特有の識別子なので、KnOSのStockコンテキストは、自動的に行のようなコンテキストである。構造においては他の任意のKnOSコンテナとは異ならないが、そのアイテムは同化されるテーブルの行Stockテーブルの各行に対する1つのKnOSアイテムを表現する。対照的に、Priceコンテキストは、Price列の特有の各ゼロでないセル値に対する1つのアイテムを有する。もし999がテーブルのPrice列に252回現れたら、KnOSは999の1つのPriceアイテムだけを有する。これは、命名された場合特有のPKとして働く単一の列を有する主リレーションを図示する。もしテーブルが異なる種類の主リレーション例えば、人間テーブルであり、人間の名前が特有でなければ、他の単一列をPK例えば、社会保障番号、または従業員番号として有する必要がある。2または3以上の列が3NFテーブルのPKとして必要とされるときはいつも、テーブルはリレーショナルモデルの連想リレーションと呼ばれ、2または3以上のテーブルと関連することを意味し、各々は3NFの中にある。これらはFKリレーションである。図3連想リレーションの同化は、タップルがユーザにより命名できない連想リレーションを示す。このStockOrderテーブルは、2つの主リレーションStockおよびOrderを関連付ける。StockOrderテーブルのPKはStockOrderである。特に、もし数千のStockアイテムおよび数千のOrderアイテムが存在したら、任意のユーザが、リレーションの各タップルに対するこの組合せを知っていそうもない。StockおよびOrderの間の連想の組合せ連想リレーションのタップルは、大き過ぎて各行に対する名前を記憶できない。例えば、誰もStockアイテムPintoBeansがOrderアイテム1111に関連するのを知ることを期待しない。その様な場合、ユーザはOrderアイテム1111に関連する全Stockアイテムの表示を求め、所望するStockアイテムを表示から選択する。または、逆に、ユーザはStockアイテムPintoBeansに関連する全Orderアイテムの表示を求め、所望するOrderアイテムを表示から選択する。もし単一の名前列が3NFテーブルに存在しなければ、連想リレーションのように、テーブルのプロキシに対する別々のKnOSコンテキストがKnOSで例示されなければならない。この特別な行のようなコンテキストの名前は、おそらくリレーショナルテーブルの名前である。これは、図3連想リレーションの同化に図示される。StockOrderリレーションのStockOrderおよびQty列は上記主リレーションのように列のようなコンテキストに同化され、StockOrderテーブルは名前プロキシとしてStockOrderコンテキストに同化される。この行のようなコンテキストのKnOSアイテムは実際の名前をもたず、人工的な名前123nだけをもつことを銘記する。これが、命名されないリレーションと呼ばれる理由である。いったん行のようなKnOSコンテキストの同化が識別されたら、バイナリ関連が各行の各列値の参照に対して確立する。これは、図5KnOSコンテキストへの関係の同化に図示される。2つの行のようなコンテナが存在し、1つはStockOrder連想リレーションのため、1つはStock主リレーションのためのものであり、それぞれコンテキスト3および1である。リレーショナルモデルの主リレーションに埋め込まれた行関係は、StockおよびPriceコンテキストに、アイテム間のバイナリ連想として、各非キー属性列へ、各行のPriceおよびPKKnOSコンテキストの各列のアイテムこの場合には、Stockの場合に記録される。図5に示されるように、これは、各列の各データ値に対して創出されたアイテムに対するベクトルキーだけを使用して達成される。同じことが、連想リレーションStockOrderの行に対しても行われる。要約すると、もしリレーショナルモデルのタップルが特有の名前IDを有する1つの列をもつなら、それは主要なまたは、命名されたリレーションと考えられる。KnOSに同化されるとき、命名されたリレーションはテーブルの各列に対する1つのKnOSコンテキストに変わる。タップル名を含む単一の列は、テーブルに対する行プロキシとして扱われるKnOSコンテキストにマップする。もしリレーショナルモデルのタップルが複数の属性または、列をPKにもつとき、連想または命名されないリレーションと考えられる。命名されないリレーションに対して、KnOSはリレーションに対するプロキシとして機能する人工的なコンテキストを創出する。リレーションの全ての列の全てのデータ値は、行毎に、各列コンテキストからこの人工的なプロキシ名前コンテキストに関連する。関係意味論的コンテキストの次元:連想分類は、KnOSに対する基本的な概念である。KnOSの一般的な実施例では、アイテムの間の全ての連想は4つの自然なカテゴリに分類され、4つの自然なカテゴリはアイテム参照に対する4つのデフォルトのVKセットに対応する。4つの連想分類は、図13にparentchildlinkおよびrelatedとして示される。自然な関連型の以下の説明は、実施例アイテムとしてcatを使用する。ParentアイテムBはアイテムAのparentまたは分類であるという意味で、アイテムAはアイテムBに属する。childはparentに属するという意味で、サブジェクトアイテムはターゲットアイテムまたは分類に属する。もしサブジェクトアイテムがcatなら、ターゲットアイテムは、例えば、animalfelineまたはpetである。ChildアイテムAはターゲットアイテムBを所有、生成、もしくは分類するという意味で、またはparentがchildもしくはchildrenを有するという意味で、アイテムAはアイテムBを有する。例えば、catはfursharpteethおよびclawを有する。LinkアイテムAは参照されたアイテムBに従事、起動、または責任を負うという意味で、アイテムAはアイテムBを行う。例えば、catはeatnapおよびmeowする。Related類似または社会的条件がアイテムAを何らかの方法でアイテムBに関連付けるという点で、アイテムAはアイテムBと同調する。例えば、我々の社会では、catはdogmouseおよびjazz即ち、coolcatおよびhepcatと関連する。これは連想リンクの最も弱いカテゴリであるが、広い概念検索において極めて有用である。加えて、アイテムは、類似または類似性例えば、単一の言語シノニム、または複数言語用語等価によりrelatedされる。関連するアイテムへの全ての参照を分類することの長所は、一般に、ブール論理積演算を使用してベクトルキーの論理積を決定するKnOSプーリングオペレーションで合致しなければならないベクトルキーの数を本質的に減少させることである。例えば、薬品試験所は、抗菌薬感受性に対して組織標本を試験する。これらの試験のデータインスタンスは名前無しである。何故ならば、試験がリレーショナルモデルの連想リレーションだからである。試験所のコンピュータシステムは、人工的な名前を各試験に対して、例えば、料金請求目的のために与える。特定の試験に対する人工的な名前は23A3442121222Jasonであり、KnOSは所定の人工的な名前を試験アイテムのデータインスタンスとして記録する。しかし、このデータインスタンスを知り、思い出し、認識するユーザがいないので、アクセスをサポートする値はない。代わりに、試験データインスタンス23A3442121222Jasonを配置しようとするユーザは、出来れば識別に近づくように十分な手掛かりを与えなければならない。例えば、ユーザは、2002年7月12日にJasonLeeによって行われた試験を見ることを求める。2つの手掛かりと一緒に提出されたそのクェリは、ゼロ、1、または多くの考えられる結果を生成する。Jasonが7月12日に行った全ての試験をユーザが見るとき、シークしているものを突き止めることが出来る。この実施例では、試験を行う試験所の技術者および日付はparentリンクとして分類される。2002年7月12日のJasonLeeの試験を探すとき、KnOSだけが試験アイテムのparentVKセットをJasonおよび2002年7月12日のchildVKセットと一緒にpoolして、ベクトルキーの一致を見付けなければならない。実際には、関連型に対する分類の任意のマッピングは、KnOSによりサポートされる。上記にリストされた4つの型は図示が目的であり、humanメモリに対して基本的であるが、コンテキストによる連想のグループ化を以下に考えるかに対する単なる示唆である。今、関係次元の正確な意味論的コンテキストを考慮する。リレーショナルモデルの殆どの専門家は、スキーマを設計し意味論的コンテキストビジネスルールを記録するためにPeterChenのエンティティ-関係モデルを使用する。殆どの場合、ビジネスルールは、isまたはhasである。質問は、意味論的コンテキストが実際には有益かどうかである。図8データ表示の比較に示される意味論的モデル等価物を考える。上記各々の場合、意味論的コンテキストビジネスルールは、isおよびhasとサブジェクトまたは、ターゲット値の組合せである。この実施例は、リレーショナルモデルの全実世界インプリメンテーションの大部分で真を保持し、それが非商用RDBMSが意味論的コンテキストをE-Rモデルから実施する理由である。この意味論的コンテキストは連想を分割または分類するための良い候補ではなく、それはサーチされなければならない関連のベクトルキーのボリュームを減少させることが出来ないことを意味し、DBMSの性能に対する利益がないことを意味する。しかし、以下のように意味論的コンテキストを再分類することは、著しい性能向上をもたらすことが出来る。辞書システムおよびASCII変換辞書システムはASCIIのために記憶されたリストを維持する独立型リポジトリであり、ASCIIセット1-255の全ての文字、従って、アルファベットの全ての文字大文字および小文字に対して、単一の桁数01239、等を含む。KnOS辞書システムが実施できる多くの異なる方法が存在する。また、追加できる辞書の数には、理論的限界が存在しない。全ての科学、言語、言語の句に対する新しいASCII辞書を追加できる。また、ユニコードの辞書も、一連の知識に基づくアジア言語または他の複雑な文字セットのサポートで実施できる。加えて、辞書は、任意のトークン、記号セット、および任意の値セットを実施するために創出できる。以下はASCIIインプリメンテーションの1つの型であり、アーキテクチャの長所を図示するが、可能な辞書インプリメンテーション方法または技術の範囲または多様性を制限するものではない。図15ASCII変換に示されるように、リポジトリ6へのアクセスが、各アイテムのデータインスタンスのASCII値の最初の2つの文字に基づくときに十分早いことが明らかになる。もしその仮定が誤りであると証明されていたら、アイテムのデータインスタンスの更に多くの文字がインデックス化される。その結果、2つの辞書コンテキストは、環境1リポジトリ6コンテキスト1および2の内部に配置される。第1のコンテキストは全コンテキスト名およびリポジトリのアイテムデータインスタンスの第1の文字に割り当てられ、第2のコンテキストは全コンテキスト名およびアイテムデータインスタンスの全ての第2の文字に割り当てられる。2つの辞書コンテキストに対する多次元参照は、1610および1620である。各辞書コンテキストは、正確に255個のアイテムを有する。ASCII文字はベース10の整数0-255に変換される必要はない、何故ならば、8ビットASCII文字は、00000000から11111111の8ビットバイナリ整数または、ベース10の0から255として自然に読み込まれるからである。ベース10の数字0-9は、ASCII文字4857である。アルファベットの26個の大文字はASCII文字6590であり、小文字は97122である。DuaneLewellynNystromEsqの最初の2つのASCII文字即ち、大文字D]および小文字uは、各々ASCII文字68および117である。データインスタンスがDuaneLewellynNystromEsqであるアイテムが人間コンテキストにベクトルキー13815を用いて追加されるとき、アイテムのデータインスタンスの最初の2つの文字に対するベクトルキーも各2つの辞書コンテキストに追加される。データインスタンスがDuaneLewellynNystromEsq即ち、13815であるベクトルキーアイテムは、各2つの辞書コンテキストに大文字D16168および小文字u162117に対するchildVKセットの内部で各々追加される。換言すれば、アイテム16168および162117は、childVKセットの内部でベクトルキー13815を各々含み、アイテム13815はparentVKセットの内部でアイテム16168および162117に対するベクトルキーを含む。KnOSベクトルキーをDuaneLewellynNystromEsqに対して検索する第1のステップは、KnOSアイテムを、ASCII大文字D16174およびASCII小文字u162117に対してコンテキスト1610および1620から各々検索することである。多くの異なるコンテキストからの多くのアイテムは、ASCII大文字Dから始まり、多くの異なるコンテキストからの多くのアイテムはASCII小文字uをアイテムのデータインスタンスの第2の文字として有する。しかし、ずっと少ないアイテムは両方の条件を満たし、更に少ないアイテムは人間コンテキスト13810に属する。ASCII大文字DおよびASCII小文字uに対するVKセットは、制御としてターゲットコンテキストERCI13810を有するベクトルプールに配置される。プーリングオペレーションは、フォーム1381Xの何れのベクトルキーが両方のVKセットに含まれるかを決定する。1381X制御要素この場合には13815に対応する2つのVKセットの小さい方にある一番下のベクトルキー要素で始めると、KnOSは一致を探す他のVKセットの最適化された2分木検索を行う。もし一致が見付かれば、図示されるように、値が答えプールへ動かされる。このサーチは、2つのVKセットの小さい方の制御フォームの全要素がターゲットVKセットでサーチされるまで継続する。図15に示される実施例では、2つのベクトルキーはプール基準13815および138124に一致する。次のステップは、参照されたフェッチを2つのアイテム13815および138124の各々に発行することである。これは2つのアイテムを、1つはデータインスタンスDuaneLewellynNystromEsqと一緒に、1つはデータインスタンスDuaneLeeGuyJrと一緒に戻す。複数ASCII値での単純な文字列比較が、DuaneLewellynNystromEsqの広域的ベクトルキーが13815であるという所望する結果を与える。これは、ASCII変換と呼ばれるプロセスを完了させる。辞書インプリメンテーションの他の方法は、コンテキストのASCII符号化アイテムの単一のセットから成る。ASCII文字を構成するデータインスタンスを有する各アイテムに対して、VKセットとして埋込要素に索引を付けられ、第2の他の文字インスタンス発生を表すASCIIの1または複数のセットが使用される。これは、第1の文字の要素としての発生により既にフィルタをかけられた第2、第3、および以降の文字の連想を有する従来の方法を超える長所を有し、プーリングオペレーションは第3および以降の文字でだけ行われる。KnOSオペレーション図10KnOSオペレーションは、如何にしてKnOSが、図1に示されるリレーショナルモデルオペレーションと比較されるコアオペレーションを行うかの実施例を示す。答えられる仮定の質問は、全stockordersのwhitebeansの総額は幾らかである。リレーショナルモデルは、この質問に1StockOrderリレーションからの射影StockおよびQty、2StockリレーションからWhiteBeansを選択、3射影と選択の結合により答える。結果は拡張され、合計されて5380を得る。上記のリレーショナル議論は、索引付けの議論を除外している。KnOSに対して、索引付けオペレーションは、辞書コンテキストで行われるASCII変換からWhiteBeansに対するベクトルキーを決定すること、およびStockコンテナを用いて検索されたアイテムのVKセットをプーリングすることを継続する。プロセスは図15ASCII変換に図示され、上記に記述される。いったんWhiteBeansに対するKnOSベクトルキー0613がASCII索引付けオペレーションから決定されたら、KnOSは同じ質問に参照されたフェッチを用いて以下のように答える。ステップ1どのstockordersがwhitebeansのためのものかデータインスタンスWhiteBeansを有するアイテム0613をStockコンテナからフェッチする。アイテム0613からStockOrderコンテキストへの任意のVKセット参照フォーム063Xのベクトルキー、即ち06310635を抽出する。ステップ2関連する量は何かアイテム06310635をStockOrderコンテキストからフェッチし、Qtyコンテキストへの任意のVKセット参照065Xを抽出する。答えは、それぞれ06510653である。06510653をQtyコンテキストからフェッチし、データインスタンス1および3を各々が有するアイテムを得る。ステップ3whitebeansの価格は幾らか上記1からアイテム0613からPriceコンテナへのVKセット参照を抽出するフォーム062Xのベクトルキー、即ち、0623。アイテム0623をPriceコンテナからフェッチして、データインスタンス1345を有するアイテムを得る。KnOS結果は拡張され、合計されて5380を得る。アイテム0623をフェッチするステップは、参照されたフェッチである。何故ならば、アイテム0623は、参照およびKnOSアドレスの両方だからである。上記のことは、要求された情報を直接的にルックアップすることにより行われる。また、KnOSは、プーリングと呼ばれるこのオペレーションの僅かに異なるバージョンも有する。PintoBeansに対してどのstockordersがQty2のQtyを有するかのような更に困難な質問をすると仮定する。この質問に答えるオペレーションが、図11プーリングの実施例に示される。プーリングオペレーションでは、VKセットがデータベースから所定の選択基準stockordersPintoBeansQty2を使用して抽出され、ブール演算を使用しての直接的な整数の比較のためにpoolに配置される。第1のステップは、Qtyコンテキストからデータインスタンス2であるそれらのアイテムを検索し、poolに配置することである。次に、PintoBeansに対するStockコンテキストアイテムから検索し、poolに配置する。最後に、StockOrderコンテキストのベクトルキー即ち、0630を検索する。整数比較をベクトルキーの最初の3つの構成要素即ち、ERCでフィルタリングとして知られるプーリングオペレーションを使用して行い、結果この場合には063Xを得る。整数比較の結果0632は、質問に対する答えである。物理的媒体上でのデータのロケーション:KnOSインプリメンテーションの各リポジトリは、ディスクベースまたは、メモリベースのシステムのファイルに類似するコンテナとして記憶される。アイテムのベクトルキーだけが、それを物理的媒体に配置するために必要である。もしアイテムのベクトルキーが既知でなければ、図15ASCII変換、および上記に記載のASCII変換プロセスを使用して最初に決定しなければならない。図16アイテム0682を物理的媒体に配置に示されるように、アイテム例えば、0682をそのベクトルキーに基づいて検索するための6つのステップが存在する。ステップ1コンテキストインデックス。リポジトリファイルから検索する第1のデータベースアーティファクトは、この場合には、リポジトリ6のためのリポジトリのコンテキストインデックスである。コンテキストインデックスは順序付けられた一連の2つの部分から成るエントリを含み、1つのエントリは特定のリポジトリの全てのコンテキストに対する。コンテキストインデックスエントリの第1の部分は、リポジトリの内部のコンテキストの実際の数であり、ベクトルキーのC次元である。ここに示される最初の4つのエントリは、リポジトリ6の最初の4つのコンテキストコンテキスト127および8を表現する。コンテキストインデックスは順序付けられているので、図16の実施例から、コンテキスト345および6は何らかの理由で削除されるか、単に決して追加されないことが明らかである。コンテキストインデックスエントリの第2の部分は、コンテキストロケータの一連の各コンテキストである。エントリの第2の部分は、リポジトリ6のコンテキスト8はコンテキストロケータの第3のコンテキストであることを示す。ステップ2コンテキストロケータ。リポジトリファイルの次のアーティファクトはコンテキストロケータと呼ばれ、コンテキストロケータはコンテキストインデックスと同じ正確な物理的構造を有する。類似のコンテキストインデックス、コンテキストロケータもリポジトリの各コンテキストに対する2つの部分から成るエントリを有するが、コンテキストロケータは順序付けられたリストではない。コンテキストロケータはコンテキストインデックスにより索引を付けられたリストである。上記のステップ1は、リポジトリ6のコンテキスト8がコンテキストロケータリストの第3のコンテキストエントリであることを決定する。コンテキストロケータリストのコンテキスト8のエントリの第1の部分即ち、1は、コンテキスト8が直ぐにコンテキスト1を物理的媒体上で処理することを示す。コンテキストロケータエントリの第2の部分は、コンテキスト8がリポジトリファイルのコンテキストセクタの第5のページで始まることを示す。これもまた、5のオフセットと呼ばれる。ページサイズは、データオブジェクト細分性および殆どのKnOSオブジェクトの平均サイズに関するリポジトリ管理に対して最適であるように定義される。無駄なスペースを最小限にし、アクセス処理能力を最大にし、動的可変長アイテムを扱うために、非常にきめ細かいアプローチが一般に使用される。しかし、ページサイズは、どの様な記憶媒体が使用されても、およびどの様なデータオブジェクトサイズが一般的であっても実行時において適合するように、および読み出し専用のデータマート、またはデータマイニングアプリケーション、またはトランザクション毎に更新される多くのアイテムを有するリアルタイム動的データモデルの何れでもKnOSの主要な目的に適合するように定義される。マルチメディアアプリケーションでは、大きなデータオブジェクト例えば、イメージまたは音ファイルが、典型的なページサイズを定義する。アプリケーションとは関係なく、1つの規則はどの2つのKnOSオブジェクトもコンテキストまたはアイテムの何れでも同じページの内部に含まれると言うことである。もし所定のオブジェクトがページを満たさなければ、ページの残りは空白のまま残される。ステップ3コンテキストBLOB。リポジトリ6の各コンテキスト、および各コンテキストの各アイテムは、リポジトリ6の物理的媒体にBLOBとして記憶される。上記ステップ2で得たロケーション即ち、5のオフセットに基づいて、リポジトリのコンテキストセクションの第5のページで始まるディスクのトラック/セクタをバッファする。バッファされたディスクトラック/セクタは、コンテキスト8により占められた4ページよりも多い情報を含むであろう。コンテキスト8に対するヘッダは、リポジトリのファイルのコンテキストセクションの第5のページで始まる。最初の4ワードはコンテキストのベクトルキーこの場合には0680であり、コンテキストのアイテムマップが続く。コンテキスト8に対するアイテムマップは、コンテキストの内部が配置されたアイテムインデックス、およびアイテムロケータであることを示す。これら2つのリストは、構造およびコンテキストインデックスおよびコンテキストロケータに対する目的が類似する。ステップ4アイテムインデックス。コンテキスト8のアイテムマップに基づいて、コンテキストのアイテムインデックスをコンテキスト8BLOBから検索する。アイテムインデックスは、順序付けられた一連の2つの部分から成るエントリを含み、1つのエントリは特定のコンテキストの全てのアイテムに対するものである。アイテムインデックスエントリの第1の部分はコンテキストの内部のアイテムの実際の数であるか、またはベクトルキーのI次元である。ここに示される最初の4つのエントリは、コンテキスト8の最初の4つのアイテムアイテム125および6を表現する。アイテムインデックスは順序付けられているので、図16の実施例から、アイテム4および5が削除されたことが明らかである。アイテムインデックスエントリの第2の部分は、アイテムロケータの一連の各アイテムである。エントリの第2の部分は、コンテキスト8のアイテム2がアイテムロケータの第3のアイテムであることを示す。ステップ5アイテムロケータ。コンテキストBLOBから検索する次のアーティファクトはアイテムロケータと呼ばれ、アイテムロケータはアイテムインデックスと同じ正確な物理的構造を有する。アイテムインデックスと同様に、アイテムロケータもコンテキストの各アイテムに対して2つの部分から成るエントリを有するが、アイテムロケータは順序付けられたリストではない。アイテムロケータは、アイテムインデックスにより索引を付けられたリストである。上記のステップ4は、リポジトリ6のコンテキスト8のアイテム2がアイテムロケータリストの第3のアイテムエントリであることを決定する。アイテムロケータリストのアイテム2のエントリの第1の部分即ち、6は、アイテム2が直ぐにアイテム6を物理的媒体上で処理することを示す。アイテムロケータエントリの第2の部分は、アイテム6がリポジトリファイルのアイテムセクタの第7のページで始まることを示す。これもまた、7のオフセットと呼ばれる。また、ページサイズは、殆どのKnOSオブジェクトのサイズに対して最適なように定義される。何故ならば、どの2つのKnOSオブジェクトコンテキスト、またはアイテムの何れかも、同じページに含まれないからである。もし所定のオブジェクトがページを満たさなければ、ページの残りは空白のままにされる。ステップ6アイテムBLOB。コンテキスト6の各アイテム、およびリポジトリの各コンテキストは、リポジトリ6の物理的媒体上にBLOBとして記憶される。上記ステップ5で得られたロケーション即ち、7のオフセットに基づき、リポジトリのアイテムセクションの第7のページで始まるディスクのトラック/セクタをバッファする。バッファされたディスクのトラック/セクタは、アイテム2により占められる2ページよりも多い情報を保持する。アイテム2に対するヘッダは、リポジトリのファイルのアイテムセクションの第7のページで始まる。いつものように、オブジェクトの最初の4ワードはアイテムのベクトルキーこの場合には0682であり、アイテムのアイテムマップが続く。これは、アイテム0682を物理的媒体に配置するのに必要なステップを完了させる。前記6つのステップは、物理的媒体アクセスの論理的議論であることを銘記する。ステップ3からのコンテキストBLOB、およびステップ6からのアイテムBLOBは、オフセット目的の別々のファイルセクションとして考えられる。実際には、図16に示される6つのKnOSオブジェクト全てが、リポジトリ6であるファイルの内部の同じ隣接する物理的媒体で索引を付けられる。コンテキストおよびアイテムは構造が非常に類似して見え、オブジェクトヘッダのオブジェクト型により区別される。また、オフセットロケータは有効アドレスであり、参照されたページIDは記憶媒体の内部アーキテクチャによって間接的に導出される。物理的媒体の更新:KnOSリポジトリは、BLOBのファイルから成る。図16アイテム0682を物理的媒体に配置に示されるように、BLOBは参照によって独立にアクセスされる。図19および図20アイテム0682を物理的媒体上で更新する-IIIに示されるように、コンテキストBLOBおよびアイテムBLOBは、リポジトリファイルで混合され、特定の順序にはない。BLOBは、効率的運用のためKnOSに順番に並ぶことを要求しない。何故ならば、全ての必要な情報は、各BLOBでカプセル化されたからである。順序独立性は、KnOSがカプセル化の特定のフォームから得る中心的長所の1つである。KnOSデータ構造の各BLOBは、ロケーションに対して索引を付けられる。ディスク上の一連のBLOBは、KnOSオペレーションの結果ではない。何故ならば、各BLOBは、その特定のBLOBに対して関連する適切な全知識を用いて完全にカプセル化されるからである。各BLOBコンテキストまたはアイテムの何れかはディスク上に配置された特定の数のページに割り当てられるので、各BLOBの最後のページは空白スペースを含む。ページサイズは、ページ上に出来るだけ少ない空白スペースを有する1ページ上に殆どのBLOBを収容するように確立される。好ましい実施例では、ページサイズはアプリケーションの最適化要求、平均BLOBサイズ、およびBLOBが記憶される物理的媒体の構造化された性質に基づいて決定される。全BLOBは、各更新によりサイズが増減する。もし更新の後に、BLOBがページの割り当てられた数字をまだ要求していたら、更新された形式でディスクに書き戻され、ページの同じブロックに書き戻される。もし更新の後に、BLOBが以前のページ割当よりも多いまたは、少ないページを要求したら、KnOSがディスクを更新するのに必要な最小仕事を評価する。BLOBの多様なサイズは、アプリケーションによって変化する。一般に、BLOBが大きくなるほど、それを動かすのは好ましくない。もし拡張したBLOBがそれ自体のスペース次のBLOBに対して配置されたスペースにまだ適合するなら、拡張したBLOBは元のオフセット位置に戻され、次のBLOBを過程の外へ動かす。KnOSは、アイテムのベクトルキーを占めているロケータ内部へ関連するインデックスを用いて、ページID参照により割り当てられた全ての隣接するページブロックのメモリに常駐するregistryを維持できる。全てのアイテムのこの物理的-論理的マッピングは、完全連想モデルを使用して実施されるメモリおよびディスク管理の異なるスキームを可能にし、1つはKnOSの内部に全体が含まれ、従って、1つは第三者にディスクオペレーティングシステムまたは、メモリ管理システムを動作させることを要求しない。追加空白スペース管理コンテキストが、データインスタンスが利用可能な隣接するページの数である1組のアイテム例えば、データインスタンスが1に等しいアイテムは、全1ページ割当のリストである、等を用いて各リポジトリで例示でき、各アイテムは、VKセット、ページロケータ参照を、サイズが各アイテムのデータインスタンスであるリポジトリファイルの使用された部分の内部で、割当解除された全ての隣接するページブロックへの索引として有する。もしBLOBサイズ増加および減少の多少の配布があれば、以下のスペースレジストリスキームが好ましい。このインプリメンテーションでは、KnOSは単に更新されたBLOBをディスクに再配置する。これを行うために、KnOSは、空白スペースコンテキストのデータインスタンスが更新されたBLOBに要求されたページの数であるアイテムに索引を付ける。そのアイテムのページID参照リストから、要求されたページ数の最後に追加された隣接するページブロックのページIDを得て、更新されたBLOBを新しいロケーションにコピーし、BLOBアイテムに対する適切なロケータ参照を更新し、ページIDを空白スペースコンテキストのアイテムのページID参照リストから削除する。次に、KnOSは、以前に占められたページブロックを、IDがページ数である空白スペースコンテキストのアイテム、ページID参照リストに追加する。例えば、もしKnOSオブジェクトが現在5ページを要求しており、7ページを要求するために更新されたら、KnOSは最初にスペースレジストリをチェックして、隣接する7ページを有する利用可能なオフセットが存在するかを見る。もし存在したら、KnOSはa利用可能な7ページのオフセットの1つを取り、b新しいスペースをスペースレジストリから削除し、c更新されたKnOSオブジェクトをそのロケーションに書き込み、dエントリの後半をコンテキストまたはアイテムロケータの何れかにおいて新しいオフセットロケーションを用いて更新し、e古い空の5ページオフセットロケーションをオープンスペースレジストリに追加する。もし要求された正確なページ数の利用可能なオープンスペースが無ければ、図19に示されるように、KnOSは更新されたオブジェクトをファイルの終わりに付加する。時間が経つとこのディスク管理スキームを用いて、割当解除されたページの中には、リポジトリファイル全体に発展するものもある図19の実施例を参照。全ディスクスペースが問題でない限り、これらのホールは問題をKnOSに提示しない。RDBMSとは異なり、ディスクが混乱するにつれてKnOS処理能力効率が著しく低下しない。ディスク上の一連のBLOBは、アクセススキームに対して重要ではない。KnOSに関する限り、ディスクファイルは本来的に混乱している。もしディスク稼働率が顧客に対して許容できない低さになれば、KnOSはバックグラウンドオペレーションを開始し、BLOBの間で割当解除された任意のページを削除する方法で、リポジトリのBLOBを新しいファイルへコピーする。参照IDにより為される、BLOBを順番に配列する試みは無い。しかし、BLOBは、コンテキストの内部でのアイテムID順序に従ってコピーできる。これは、全アイテムをリポジトリで線形化し、もしコンテキストコンテンツがリポジトリからそのまま要求されることが多ければ、ディスクヘッドシークタイムを減少させることが出来る。さもなければ、既存のBLOB順序が新しいディスク領域にコピーされる。コピーの目的は、BLOBを端と端を接して配置し、BLOBの間の割当解除された任意のページを削除することである。これは、KnOSの現在のオペレーションを乱すことなく行われる。もし移動された任意のBLOBがオペレーティングシステムによりアクセスされたら、コピープロセスの終わりまで更新は単にキャッシュされ、キャッシュされた更新がディスクに書き込まれる。他のスキームでは、図19に示されるようなeviction方法が使用される。この方法を用いて、割当解除されたページ問題は事実上存在しない。もし起動されたら、各アイテムが増大するにつれて、増大するのに必要なスペースは、過程の内外でスペースを占めるアイテムを、リポジトリの使用された部分の終わりの空白スペース、またはスペースレジストリで見付かった適合サイズの空ページブロックの何れかへ動かすことによって供給される。次に、もたらされたスペースが、増大したアイテムに割り当てられる。アイテムは殆どのアプリケーションで増大しようとするので、如何なる空白スペースもアイテムは過程をクリアすることにより得て、結局は増大を続けるアイテムになじむ。この方法では、アイテムを削除することにより残されたスペースは、メモリで処理するアイテムに割り当てられるか、または新しいか移動されたアイテムへの再割当のためにスペースレジストリに追加されるかの何れかである。コンテンツアウェアネス:KnOSインプリメンテーションは、キーワードサーチ、および限定されたテキストサーチ機能を、構造化されたデータアプリケーションの中心的実施例の一部としてサポートできる。例えば、構造化されたデータアプリケーションを有する企業も、テキストサーチ、およびキーワードサーチ機能を全従業員のレジュメに提供する要求を有する。以下は、それが如何にしてKnOSで行われるかである。第1に、各人のレジュメは、人間アイテムの埋込アイテムとしてマルチページPDF形式Adobeシステムで追加される。次に、レジュメは、図13KnOSアイテムの構造の埋込アイテム即ち、電話番号、および住所と類似して出現する。レジュメのPDFはBLOBとして単に記憶されるか、または各人間のアイテムの内側のBLOBと比較される。第2のステップは、Keywordコンテキストを確立して配置することである。このコンテキストは、全レジュメの結合、アーティクル、等でない自明でない各ワードに対して1つのアイテムを含む。ワード自体は、キーワードコンテキストの各アイテムに対するアイテムのデータインスタンスである。新しいまたは、改訂されたレジュメが人間コンテキストに追加されるときはいつも、特定の人間に対する以前の全ての連想キーワード参照が削除され、レジュメの各々の特有の自明でない全てのワードに対する新しい連想参照がキーワードコンテキストに追加され、もちろん、特定の人間のアイテムに対して双方向である。キーワードコンテキストの各アイテムは、人間コンテキストの正しい人間アイテムに対するベクトルキーを含む。例えば、もしレジュメワードがcarpentryなら、データインスタンスcarpentryであるキーワードアイテムは、ベクトルキーの特定のVKセットを、レジュメにワードcarpentryを有する全ての人間に対して含む。テキストサーチをレジュメで行うために、ユーザはサーチのためにワードの文字列を入力しようとする。各サーチワードは最初にASCIIに変換され、各サーチワードに対するキーワードアイテムベクトルキーを決定するこれが如何に行われるかの実施例のために図15ASCII変換を参照。次に、各サーチワードに対する正しいキーワードアイテムが人間コンテキストと一緒にプールされ、どの人間アイテムがそれら正確なワードをもつレジュメを有するかを決定する。この手続きは、図11プーリングの実施例に示されたプーリングオペレーションと同じである。プーリングオペレーションの結果は、レジュメが全てのサーチキーワードを有する全ての人間に対するベクトルキーのリストである。人間データインスタンスのリストはユーザに戻るか、または人間アイテムの単純な検索は実際のレジュメを埋込PDFとして生成する。PDF形式のレジュメを各人間アイテムに追加することは、相当なサイズを各人間アイテムに追加する。もし人間アイテムの日常的使用がレジュメを要求しないなら、レジュメの実際のPDFをレジュメと呼ばれる別々のタグセットコンテキストに埋め込むことが処理能力効率のために有利であるタグセットコンテキストの説明は以下を参照。次に、実際のレジュメPDFは必要なときだけ検索され、個人アイテムが検索される各時間には検索されない。実際には、これは、何かが埋込アイテムとしてベースアイテムに含まれるべきかどうかの一般化された試験の一部である。旧式のデータベースをKnOSデータベースに同化する:実際問題として、殆ど全部の企業がデータの旧式のリポジトリをテーブル形式でもっている。DBMSとしてのKnOS発明の有用性は、テーブルに記憶された多量の旧式のデータを吸収し同化する機能により大部分が判断される。大体は、この旧式のデータは調整されていない単層ファイルに存在し、理想的な正規3NF形式には存在しない。KnOSは、完全に正規化されたリレーショナル構造を吸収したときに最も良く機能する。1組の正規化された3NFリレーショナル構造、および関連するデータは、うまく定義されたプロセスによりKnOSコンテキストおよびアイテムへ変換または同化できる。リレーショナルデータベースは3つの型の正規化されたリレーションテーブル命名された主リレーション、命名されない連想リレーション、およびルックアップから成り、各々はKnOSへ別々に同化される。このセクションは最初に、如何にして図1リレーショナルデータモデルに示されるリレーショナルデータベースがKnOSに同化されるかを記載した。殆どの旧式のアプリケーションはリレーショナルテーブルではない単層ファイルを使用するので、セクションの残りは、如何にして単層ファイルが処理されて、あたかもリレーショナルデータベースかのように同化目的をカバーするかを記載する。命名された主要なリレーションを同化する:名前は、リレーションテーブルの各タップル行に与えられる特有の識別子である。名前として適格であるものに対して、それは特有でなければならず、ユーザがそれを識別できなければならない。ユーザが命名できるリレーショナルタップルがあり、他は命名できないことは紛れもない事実である。これは、ユーザが命名するには複雑すぎるリレーションがあるからである。命名されないタップルは、手掛かりをそれらの存在に与えることによってのみ記述できる。リレーショナルモデルでは、命名されたリレーションは最も頻繁に呼ばれる主リレーションである。命名されたリレーションの特別な場合、ルックアップリレーションは、主リレーションとは考えられない。これらに対して、以下のルックアップテーブルの同化のセクションを参照。図1-図2では、Stock主リレーションは命名されたリレーションであり、そのタップルはPintoBeans、KidneyBeans、WhiteBeansおよびWaxBeansと命名される。命名されたリレーションの他の全ての特有の列は、1つの列として各コンテキストに同化される。以前に記載したように、KnOSコンテキストは、リレーショナル列または属性に類似する。図3に示されるように、Stock主リレーションは2つのKnOSコンテキスト1つのコンテキストはStock属性に対して、1つのコンテキストはPrice属性に対して同化される。もしより多くの属性がStockリレーションに存在したら、特有の各属性はそれ自体のコンテキストをKnOSに有する。もしコンテキストが同じなら、属性はKnOSと特有の基準に基づいて同化する。もしPrice属性が同じ関係コンテキスト例えば、何かの価格の4つの異なるリレーションに出現したら、KnOSは1つのPriceコンテキストだけを有する。次に、Stock主リレーションの各タップルは、KnOSの命名された属性コンテキストこの場合には、Stockコンテキストのアイテムに割り当てられる。命名された各行は、アイテムを命名されたコンテキストに有しなければならない。図2に示されるように、Stockリレーションの4つの行はStockコンテキストの4つのアイテムを意味し、1つは命名された各アイテムに対するものである。主リレーションの他の全ての属性に対して、1つのKnOSアイテムは属性の特有の各値に対して創出される。price属性に対して、異なる各価格に対する1つのアイテムが存在する。この場合、4つの価格は4つのアイテムを意味する。もしPintoBeansおよびKidneyBeansの両方が1ケース当たり1110かかれば、Priceコンテキストは3つのアイテム即ち、11101345および1872だけを有する。命名されたリレーションの各タップルは、多くの埋込関係を表現する。関係を各タップルの内部に記録するために、VKセットは各コンテキストに挿入され、StockおよびPriceの間の関連を完全に記述する。完全な同化は、図5に示される。命名された各リレーションは、この方法で同化される。命名されない連想リレーションを同化する:リレーショナルモデルでは、命名されないリレーションが最もよく呼ばれる連想リレーションである。何故ならば、それがリレーションの複雑な関連を記述するために使用され、FKによって定義されるからである。その複雑さのために、一般に連想リレーションは個々のタップルを参照する便利な名前をもたない。図3連想リレーションの同化に示されるように、StockOrderリレーションは連想である。図8データ表示の比較の下部に示されるように、それは、命名されたStockPintoBeans、KidneyBeans、WhiteBeansおよびWaxBeansを命名された顧客注文番号111111171118および1119に関連付ける。連想リレーションStockOrderは2つの命名されたリレーションStockおよびOrderを関連付けるが、それ自体は命名されたリレーションではなく、ユーザがリレーションの個々のタップルを直接的に命名できないことを意味する。リレーショナルモデルに対して、KnOS設計は、命名されたコンテキストに全てのリレーションに対してリレーションのタップルを表現することを要求する。だから、もし所定のリレーションが名前無しタップルが単一のPK属性によって一意に識別できないならば、KnOSは別々のプロキシ命名されたコンテキストを特定のリレーションに要求する。図3に示されるように、KnOSのプロキシStockOrderコンテキストは、リレーショナルタップルが名前無しであるのと同じ理由で名前をアイテムにもたない。特別なプロキシコンテキストをリレーションに対して創出する以外に、命名されないリレーションは同一の方法で命名されたリレーションに同化される。命名されたリレーションと命名されないリレーションの違いは、図2-図3で最も明らかである。命名されたリレーションは、1つのKnOSコンテキストとしてリレーションの全ての属性に対して別個のコンテキストを用いて同化され、命名されないリレーションは、1つのKnOSコンテキストとしてリレーションの全ての属性に対して1つのプロキシ命名されたコンテキストを命名されないリレーション自体に対して同化される。図3では、プロキシコンテキストは、コンテキスト3StockOrderである。命名されないリレーションに対するいわゆるプロキシコンテキストは単なるリレーショナルセンスのプロキシであり、リレーショナル理論と比較して、それは命名されないリレーションに対するプロキシであることを銘記する。KnOSに関しては、他の任意のコンテキストと区別がつかないのはコンテキストである。もし、リレーショナルモデルを先例とせずに、データモデルを最初から創出したら、規則が当てはまらない。代わりに、KnOSモデルは、1つの行のようなコンテキストを全ての概念に対して、および1つの列のようなコンテキストを別個のコンテキストを有する全ての属性に対して保持する。連想リレーションは、リレーション自体を表現する1つのKnOSコンテキスト、およびリレーションの特有の各属性に対する1つのKnOSコンテキストに同化する。StockOrderリレーションは、プロキシStockOrderコンテキスト、およびリレーションのStockOrderおよびQty属性に対する1つのKnOSコンテキストに同化する。図2と同様に、ベクトルキーはVKセットに連結され、3つの属性をリレーションに関連付けるリレーションを反映するコンテナでカプセル化される。図5KnOSコンテキストへの関係の同化は、如何にして命名されたリレーション、および命名されないリレーションが同化の後にKnOSに出現するかを示す。図5の上部の2つのリレーションは、構造に関してアプリケーションに大きく依存する。図5のリレーショナルリレーション下部の5つのKnOS構造は全て同じであり、特定のアプリケーションに依存しない。各アイテムは同じ正確な物理的構造VKセット、および含有される任意のアイテム埋込要素が続く名前または、名前プロキシを含むデータインスタンスが続く自己参照ベクトルキーを有する。ルックアップリレーションを同化する:リレーショナルデータベース設計は、属性レベル一貫性を、ルックアップリレーションと呼ばれる特別な命名されたリレーションにより達成する。ルックアップリレーションは、所定の属性に対して許容される値のドメインを記録するために使用される平凡なリレーションである。ルックアップリレーションは、2つの列属性値に対するプロキシである人工的なキーAK、および属性データ値自体である名前を有する。機能アプリケーション内部の許可は、誰が値を追加、編集、またはルックアップリレーションから削除できるかを制限する。ドメインを制限された属性を使用する各リレーションでは、AKプロキシは常に属性データ値に取って代わる。ルックアップテーブルは、KnOSと同化する第1のものである。KnOSがAKを同化しないと仮定すると、各ルックアップリレーションは、1つのKnOSコンテナに同化する。ルックアップリレーションを使用する命名されたテーブル、および命名されないテーブルがKnOSに同化されるとき、AKプロキシ関係は、ルックアップ属性を表現するコンテナへの直接的関係を支持して削除される。例えば、リレーショナルアプリケーションは、ちょうど3つの値red、blueおよびgreenに対する属性Colorを制限するために選択する。アプリケーションのユーザが他の色をリレーションに割り当てないことを保証するために、Colorと呼ばれるルックアップリレーションが、ちょうど3つのタップルred、blueおよびgreenを用いて創出される。これらは、1、2および3の値を有するプロキシ属性ColorCodeAKを各々割り当てられる。リレーショナルデータベースの残り全体を通して、プロキシ属性ColorCode123が、Colorred、blue、green自体の代わりに使用される。この実施例では、KnOSは最初に、Colorルックアップリレーションをデータインスタンスredblueおよびgreenである3つのアイテムを有するColorコンテキストに同化させる。AKColorCodeがリレーションの同化に遭遇するたびに、KnOSはColorCode123AK属性をColor属性に対するKnOSベクトルキーを支持して削除し、3つのアイテムの1つをColorコンテキストred、blue、greenで表現する。リレーショナルデータベースからの連想は保存されるが、AKColorCodeはKnOSインプリメンテーションで生き残らない。KnOSベースの機能アプリケーションは、誰がColorコンテキストでアイテムを追加、編集、または削除できる/できないかに関する類似した許可制御を設けなければならない。これは、ルックアップリレーションがリレーショナルインプリメンテーションで遂行する同じ属性レベル一貫性を行う。単層ファイルを同化する:前記3つのセクションは、如何にして完全に正規化されたリレーショナルデータベースがKnOSに同化されるかを記載する。しかし、多くのデータベースのKnOS形式への同化は、リレーショナルテーブルではなく単層ファイルに由来する。また、単層ファイルはテーブルであるが、正規化命名された、命名されない、またはルックアップのリレーショナル規則に従わない。単層ファイルは、特定のアプリケーションをサポートするユーザビューによって代わりに編成される。その結果、単層ファイルは余りに混乱していて、直接的に同化できない。KnOS形式に同化されるために、以下のセクション正規化と呼ばれるリレーショナルプロセスに記載されるように、単層ファイルは最初にマークアップされなければならない。いったん各単層ファイルがマークアップされて、以下に記載するように準備されたら、以前のセクションに記載されるように、KnOS形式に同化される。KnOS形式に同化する前に、単層ファイルを準備して、リレーショナルテーブルに分割する必要はない。マークアップは単層ファイルに適用されて、単層ファイルが、命名された、命名されない、またはルックアップリレーショナルテーブルのようにソフトウェアによって同化されることを可能にする。以下のセクションは、リレーショナルテーブルのように単層ファイルを解析およびマークアップするためのプロセスを記載する。単層ファイルを同化するために、KnOSは以下に記載される単層ファイルマークアップを読み込めるアシミレータと呼ばれる1本の特殊目的のソフトウェアを必要とし、情報を単層ファイル形式からKnOS形式に変換する。不必要なデータを識別する:単層ファイルを変換する第1のステップは、不必要なデータを識別することである。時間が経過するにつれて、単層ファイルに基づく任意のコンピュータシステムはデータの不必要な列を要求する。もはやアプリケーションソフトウェアによって使用されない単層ファイルの内部の情報の列が存在する。データの不必要な列を識別する最も単純明快で正確な方法は、単層ファイルの種々の列への新しいユーザビューの所望するセットの各要素をマップすることである。このプロセスは、ビューモデル化と呼ばれる。ビューは単層ファイルの情報最も一般にはスクリーン、レポート、およびインターフェースとの任意のエンドユーザ対話である。この方法で、いったん単層ファイルがビューにマップされたら、単層ファイルの列の多くは要求される任意の機能にアンマップされそうである。単層ファイルのこれらの列は不必要なデータの候補であり、それらは同化されない。不必要な列の初期マークアップは、情報が本当に必要でないことを確認するために、新しいアプリケーションのユーザによりチェックされなければならない。不必要としてマークされた殆どの情報は、色々な出来事に追い越された旧式のアプリケーションの属性である。情報は単層ファイルに配置され、以前のある時期に旧式のアプリケーションに役立つ。旧式のアプリケーションが変更されて機能が削除されるとき、単層ファイルは訂正されず未使用の情報を削除する。旧式のアプリケーションが古いほど、データの更に多くの不必要な列が単層ファイルに含まれる。データの不必要な列候補は、情報を処理するための単層ファイルアプリケーションソフトウェアによって使用される物理的表示フラグ、インジケータ、等であることが多い。そのようのフラグ、およびインジケータは、新しいアプリケーションによって要求されてもされなくてもよい。そのようなフラグまたはインジケータの各々は、特定のフラグまたはインジケータが他の手段新しいアプリケーションのソフトウェアによって再確立できることを確認する新しいアプリケーションの挙動モデルと照合されなければならない。もしされなければ、フラグまたはインジケータを含む列が、同化のためにマークされなければならない。導出されたデータを識別する:第2のステップは、導出されたデータを識別することである。ユーザビューにマップしない単層ファイルの情報の多くは、データの他の必要な列から直接的に導出できるデータ値である。導出されたデータ例えば、数値の全列は単層ファイルに配置され、コンピューティングリソースの役に立つ。導出されたデータが新しいアプリケーションによって必要とされてもされなくても、それは決して同化されない。代わりに、導出されたデータはユーザのアプリケーションによって実行時において導出されるか、または、もし導出されたデータが記憶されたら、KnOSによって同化の時に再度導出される。単層ファイルの導出されたデータの全ての列は、同化に対して不必要なように識別され、マークされなければならない。KnOSに記憶される導出された任意のデータに対して、ファイルマークアップは、導出アルゴリズムを含まなければならない。アシミレータソフトウェアのプリプロセッサは、導出されたデータをアルゴリズムから再現しようと試み、単層ファイルに含まれる導出されたデータに対する差異をリポートする。そのような差異は、差異が有効であること即ち、アルゴリズムが正確であることを保証するために、新しいアプリケーションのユーザによりチェックされなければならない。複合情報を解決する:ステップ3は、複合情報の解決である。単層ファイルの複合情報は、ソートおよび印刷のような特別な目的のためにまたは、特別なプロセッシング条件を起動するためにアトミック属性の連結から成る導出されたデータの形式である。複合情報のそのような各列は、解析されて解決されなければならない。複合情報の列は、単層ファイルの他の任意の列に出現しない必要なデータの1または複数のカーネルを含むことが多い。これらの場合、単層ファイルは前処理されて、情報の必要なカーネルを複合属性から抽出し、それを単層ファイルの新しい列に同化目的で配置する。いったん必要なカーネルが単層ファイルの新しい列から抽出されたら、複合情報の列は不必要および、同化されないとしてマークされる。レコードコピーをマークする:ステップ4は、複製を識別し、コピーまたはレコードをマークすることである。同化プロセスの最も異なる部分は、情報の複製された列の間の同期エラーに関する。単層ファイル全体の情報属性の列が、複製されそうである。複製された属性が同じ主キー値に対して異なる値を有するときはいつも、同期エラーが発生する。同期エラーは識別されなければならず、レコードのコピーは同化即ち、異なる値の何れが正確かに対してマークされなければならない。属性の残りの複製は、不必要であるおよび、同化されないとしてマークされる。このプロセスの第1のステップは、複製された属性の主キーを識別することである。次に、KnOS同化プリプロセッサは、主キーの特有の各値を複製された属性の全ての値と比較しなければならない。理想的な状況では、主キーの単一の特有の各インスタンスに対して、全ての複製された属性は同じ値をもつべきであるこれが、結局、複製の意味である。プリプロセッサが多数の違反を見付けそうなこの条件をチェックするとき、複製は本当の複製ではない。コンピュータ化されていないプロセスが、これらの異なる値の何れが正確な値かを決定できる。主キーも誤って査定され、複製は本当の複製ではない例えば、実際には、異なるアドレスは料金請求アドレス、送り状アドレス、等である。これらの場合、複製された単層ファイル列に対して主キーを訂正することが、同期エラーを訂正する。同期していない本当の複製に対して、アナリストはアプリケーションのユーザにより同期エラーを確認しなければならず、識別された各データの完全性エラーに対する処置を決定しなければならない。最善の結果は特定の複製された列がレコードのコピー即ち、同化されるデータの列であることを決定するユーザ人口に対するものであり、それにより他の全ての複製された列が不必要であるおよび、同化されないとしてマークされることを可能にする。ユーザは、各同期エラーが個々に解決されることを要求する。この解析の結果は、同化ソフトウェアによる使用に対して保存される。正規化されたテーブルを識別する:ステップ5は、単層ファイルの正規化である。単層ファイルの情報の残りの各必要な列に対して、アナリストはその主キーその列の値を一意に識別する単層ファイルの情報の1または複数の列を識別しなければならない。この行為は正規化されたリレーショナルテーブルを単層ファイルの内部で識別する。何故ならば、異なる各主キーが異なる正規化されたテーブルを表現するからである。単層ファイルを別々の正規化されたテーブル構造に分解する必要はない情報の各列が正しい主キーでマークされたら関連していたら、正規化されたテーブルは単層ファイルの内部で共存できる。KnOSでは、各主キーは1つの行のようなコンテキストに一意に関連する。人工的なキーを識別する:ステップ6は、人工的なキーの識別および削除である。テーブルは人工的なキーAKを有することが多く、人工的なキーは特有であるように創出された識別番号である。AKは、長いASCII文字列であるか、または特異性問題を有するPKに取って代わることが多い。例えば、ユーザ名は個人テーブルの本当のOKであるが、名前は索引付け目的のためには長すぎ、2人の人間が同じ名前を有するかもしれない。もし便利な特有の社会保障番号のような数字PKが存在したら、一般に単層ファイルはそれを保持する。もし主リレーションを番号付けするための便利な特有の数字が存在しなければ、単層ファイルはその目的のためのAKを保持する。もし、そのようなAKが単層ファイルに存在したら、それらは不必要であるとして識別されなければならず、同化されない。代わりに、正しいPKを、AKが取って代わられたユーザアクセス可能な属性の1または複数の列として識別する。いったん正しいPKが各AKに対して識別されたら、単層ファイルの任意の特異性問題はアシミレータの前処理を用いて識別されなければならない。もし所定の正規化されたテーブルに対する正しいPKが同じ値であるが異なるAKをもつなら、重複するPK値はアプリケーションのユーザにより解決されなければならない。同化のとき、値が特有になるように、スキームは決定されなければならない。解決スキームは、文字列例えば、JohnPaulJones1JohnPaulJones2の最後に整数を追加することに過ぎない。単層ファイルの正しいPKは、一貫性エラーを解決する前に特有の値に変換されなければならない。複数主キー候補を選択する:ステップ7は、複数候補が存在するときにPKを選択することである。単層ファイルの情報の必要な列は、そのPKに対して複数候補を有することが多い。これが起きるとき、アナリストは複数キーを同化する最善の方法を決定しなければならない。候補の1つは、KnOSに対する主要なキーとして選ばれなければならない。全ての非キー列および残りの候補PKは、同化の時の主要なキーに関連する。性能的理由のために、主要なPKを候補の中から選ぶとき、いくらかのケアが行われる。例えば、ユーザ名および社会保障番号は、個人テーブルに対して競合する候補PKである。命名された行のようなコンテキストが使用できてもできなくても、それは人間テーブルに対して同化される。テーブルのレコードにアクセスするためにユーザによって使用されることが多いものに基づいて、選択が行われるべきである。もしユーザが名前によって人情報にアクセスすることが最も多ければ、人名は主要なキーに対する正しいデータインスタンス値である。いったん主要なキーが選択されたら、他のPK候補は処置のために評価されなければならない。もし人名がKnOSの人間コンテキストに対する正しい属性なら、SSNはそれに密接に結び付けられるべきである。特に、もし著しい独立したアクセスをもつなら、SSNはそれ自体のKnOSコンテキストをもつ。しかし、人名が使用される全ての時に、SSNも要求されるようである。もしそうなら、それはSSNを個人コンテキストのアイテム埋込要素として扱う性能に有利である。そのような決定は、同化の前に行われる。一貫性エラーテーブルレベル一貫性を解決する:ステップ8は、テーブルレベル一貫性の確立である。いったん、このマークアップが完了したら、単層ファイルは前処理されて参照一貫性エラーを識別しなければならない。単層ファイルのPKの所定の値が複数回だけPKが識別するデータの列に対する異なる値によって出現するときはいつも、参照一貫性エラーが出現する。換言すれば、もし所定のPKが列A,BおよびCを識別しPKの所定の値インスタンスが複数回だけ出現したら、A,BおよびCの値は各出現に対して同じでなければならない。もし同じでなければ、それは単層ファイルのテーブルレベル一貫性エラーである。参照一貫性エラーは、2つのこと識別されたPK構造が正しくないこと、または不正な値が単層ファイルに存在することの中の1つである。いったん、PK構造エラーが訂正されたら、残りの不正な値はアプリケーションのユーザにより確認および解決されるべきである。異なるユーザ人口は、単層ファイルの参照一貫性エラーを訂正するための確認アプローチを有する。あるものは、同化ソフトウェアが、多数の値例えば、最初の1つが遭遇するという推測の1つを任意に選ぶことを可能にする。他は、各参照エラーが解析によって解決されることを要求する。極端な場合、実際にはユーザが単層ファイルを再編成して、エラーを削除してもよい。参照一貫性エラーを解決する方法は、特定のインスタンスにおける精度に付随する重要性の程度に依存する。ルックアップ属性レベル一貫性を標準化する:ステップ9は、属性レベル一貫性の確立である。単層ファイルの多くの列は、ルックアップ値として識別される。これらの場合、ユーザは属性に対する値の範囲を指定して、属性レベル一貫性を新しいアプリケーションで確立する。単層ファイルにおける値の範囲は、ほぼ確実に、新しいルックアップ属性に対する値の所望する範囲に一致する。KnOS同化ソフトウェアは、単層ファイルルックアップ値対標準化されたルックアップ値のユーザマップを受け入れる機能を有する。最初に、アシミレータは、特定のルックアップ列の値の範囲を、その列に対してユーザにより選択された値の標準的な範囲と比較する。一致しない値は、一致する値にマップされる。このプロセスは、値の標準的なリストにおける変化を必要とする即ち、範囲外の値のいくつかは、標準的なリストを編集したときにユーザが識別できなかった正しい値である。いったん完了したら、ルックアップとしてラベルを付けられた任意の列を同化するときに、アシミレータソフトウェアはこの相互参照マッピングを使用する。これは、単層ファイルの処理を完了させる。今、それは、命名された、命名されない、およびルックアップリレーションのためのリレーショナル標準化規則、およびKnOSへの同化に適したリレーショナル標準化規則に一致するような方法でマークされる。拡張された構造分類、およびコンテキスト:いくつかのアプリケーションでは、特定のKnOSコンテキストは、非常に大規模なVKセットを有する連想スコープにおいて非常に複雑なアイテムを有する。極めて大きなアイテムは、処理が更に困難である。何故ならば、それらのコンテキストが非常に広範だからである。もし、所定のコンテキストのコンテキストの処理が困難であれば、コンテキストのVKセットはコンテキストまたは、分類に基づいて1または複数のタグセットコンテキストにカプセル化できる。KnOSタグセットは、分類または分類法をデータベースに記録するために使用されるコンテキストの特別な型である。タグセットコンテキストは、任意の独立したアイテムを保持しないことを除いて、標準的なコンテキストと同じ物理的構造をもつ。代わりに、タグセットコンテキストのアイテムは効果的に複製されるか、またはアイテムを他のコンテキストで表現し、他のコンテキストはベースとして、またはタグセットコンテキストのコンテキストに基づいて参照される。タグセットコンテキストアイテムのVKセットは、何らかのサブセット、または対応する基になるコンテキストアイテム、または新しく創出されたコンテキストに適用可能な連想の別個の新しいセットのVKセットにより定義された連想の分類の何れかを記録する。換言すれば、タグセットコンテキストは、連想の特定のコンテキストを、その中のアイテムに対するVKセットのサブセットとして記録する。3つの型のタグセットコンテキスト標準的、マルチパス、および複合が存在する。標準的なタグセットコンテキストは、任意の標準的なコンテキストから創出できる。マルチパスタグセットコンテキストは、他の標準的なタグセットコンテキストに基づく。複合タグセットは、1または複数のベースコンテキストからのアイテムの選択された収集で構成される。以下の議論は、分類を向上させるために3つの型全てのタグセットの使用を記載し、コンテキストおよび性能を向上させる。もし機能アプリケーションがそれを区別できたら、コンテキストは性能を向上させることだけをできることは明らかである。もし、分類法または分類がアクセスを行う機能アプリケーションに見えなければ、アプリケーションはコンテキストによって情報にアクセスできない。もし特定のコンテキストがアプリケーションに見えなければ、KnOSはコンテキストからの改良の長所を取る基準をもたない。本当に、それは実際にはKnOSを遅くする。何故ならば、ものを探すための場所を更に創出するからである。標準的なタグセットコンテキスト:標準的なタグセットコンテキストは、任意の標準的なKnOSコンテキストに基づく。標準的な場合には、タグセットコンテキストは基になるコンテキストと同じ数のアイテムをもち、対応するアイテムのデータインスタンスも同じである。この点アイテムの数、データインスタンス、および構成では、標準的なタグセットコンテキストは、基になるコンテキストの正確な複製である。次に、コンテキストの中には、基になるコンテキストのVKセットに適用されるものもある。選択されたコンテキストに基づいて、一致する1または複数のVKセット要素は、ベースコンテキストアイテムから合致する標準的なタグセットコンテキストアイテムへ移動させられる。ソフトウェアアプリケーションがその所定のコンテキストで動作するときはいつも、基になるコンテキストの代わりにタグセットコンテキストにアクセスする。アプリケーションが所定のコンテキスト以外のコンテキストで動作するとき、基になるコンテキストまたは、他のタグセットコンテキストを使用する。今、ベースコンテキストは使用するには非常に単純である。何故ならば、所定のコンテキストが削除されたからである。タグセットは、データおよびビューモデル化の両方のために処理能力性能および一般的な編成を改良するKnOS分類ツールである。例えば、製造アプリケーションの部分コンテキストは極めて複雑なアイテム関係をもちそうであり、その結果、非常に大規模なVKセットをもつ。部分コンテナの連想の1つの有望な分類またはコンテキストは、billofmaterialsBOMである。もし所望するなら、部分コンテキストでVKセットにより定義されたBOM連想は、BOM標準的なタグセットコンテキストにカプセル化できる。partと呼ばれる標準的なコンテキストKnOSは、そのアイテムデータインスタンスとして、全部分の部分番号をもつ。BOMと呼ばれるタグセットコンテキストは、部分コンテキストの各部分に対して1つのアイテムを保持するように確立され、各アイテムは同じアイテムデータインスタンスを有する。BOM連想を表す部分コンテキストのparentおよびchildVKセットは部分コンテキストから除去され、BOMタグセットコンテキストに配置される。他の全てのVKセットは、部分コンテキストに残される。これは全てのBOM分類の複雑さを部分コンテキストから除去する効果をもち、従って、部分コンテキストのアイテムのサイズを減少させ、BOMプロセッシングに関係しない部分を含む任意のアプリケーションに対する処理能力を改良する。アプリケーションがBOMを必要とするときはいつも、部分コンテキストの代わりにBOMコンテキストを呼び出す。KnOSは、タグセットコンテキストのアイテムと基づいているコンテキストの間の1対1マッピングを自動的に維持する。この場合、アプリケーションソフトウェアはアイテムを追加されないか、またはアイテムをKnOSタグセットコンテキストから削除しない。アイテムの追加および削除は、KnOS動作環境により処理される。アイテムは決して削除されないが、本来的に、それらは単にゼロであるVKセットをもつ。アイテムが基になるコンテキストに追加されるときはいつも、アイテムはタグセットコンテキストに追加されるだけであり、対応するアイテムが基になるコンテキストから削除されるとき、アイテムはタグセットコンテキストから削除されるだけである。例えば、もしアイテムが部分コンテキストから削除されたら、KnOSもBOMコンテキストの部分への全ての参照を削除し、BOMアイテム自体および任意のVKセットの両方がそれを参照する。VKセットタグセットコンテキストは、基になるコンテキストに従属する任意のVKセットである。いくつの別個の連想コンテキストが標準的なコンテキストで識別されるかに、制限はない。標準的なKnOSコンテキストは、任意の数のタグセットコンテキストに対する基準であり得る。例えば、部分-ベンダ連想も部分コンテキストから除去され、部分-ベンダPTVと呼ばれるタグセットコンテキストに配置される。次に、誰が所定の部分を供給できるかに関するクェリがPTVコンテキストを呼び出し、部分コンテキストを呼び出さない。この方法では、ベンダコンテキストが、部分コンテキストからカプセル化される。同じことがベンダコンテキストにも行われ、それにより部分連想をベンダコンテキストからベンダ-部分VTPコンテキストへセグメント化する。タグセットコンテキストは、合致するタグセット例えば、VTPコンテキストを他の方向に創出することなく、1方向例えば、PTVに創出できる。タグセットは独立に注入でき、コンテキストまたは処理能力を向上させる。もしコンテキストまたは処理能力が向上しなければ、コンテキストによるVKセットによって定義された連想を分類するために、タグセットを注入する必要はない。以下に記載されるマルチパスの除外により、1つのタグセットコンテキストは他のタグセットコンテキストには基づかない。上記の実施例では、PTVコンテキストでVKセットにより定義された連想は、本当のベンダコンテキストのアイテムだけを指し、VTPコンテキストの連想は、本当の部分コンテキストのアイテムだけを指す。PTVコンテキストのアイテムはVTPコンテキストのアイテムを参照せず、逆も同様である。そのような分類/コンテキストは、いつでも注入でき、カプセル化でき、またはKnOSから除去で生きる。従って、タグセット分類は、KnOSにおける強力な調整ツールである。例えば、もしプロセスの任意の点で、BOM連想が部分コンテキストを処理するには不必要に複雑にまたは、遅すぎるようにしていると決定されたら、BOMタグセットコンテキストが創出できる。いったん創出されたら、もし不必要であると決定されたらBOMタグセットコンテキストはいつでも削除できる。BOMコンテキストのVKセットは、部分コンテキストの対応するVKセットと単にマージされ、BOMコンテキストは削除される。KnOSタグセット技術は、コンテキストに基づいて機能する。更に多くのコンテキストがKnOSデータベースに存在するほど、処理は早くなる。例えば、汎用部分コンテキストからよりも専用のBOMコンテキストからBOMクェリを処理した方がはるかに早い。これは、BOMコンテキストが限定されたコンテキストを有するからである。必要なとき、さもなければ無視されたときに、それは呼び出される。部分コンテキストに反するオペレーションは、BOM連想に負担されない。また、それは、KnOS競合がコンテキストの間に存在しないことを意味する。KnOS分類スキームを、リレーショナルモデル本来の2つの類似した処理能力問題即ち、密度が低い行列、および行レベル競合と混同しないことが重要である。リレーションの属性が全てのタップルに当てはまらないときはいつも、密度が低い行列が出現する。この問題を調整するためのリレーショナルアプローチは、異なる分類をリレーションの内部で識別し、一般的リレーションの密度が低い部分を1または複数のカテゴリリレーションにセグメント化することである。換言すれば、データベースを正規形にする。もし多すぎるユーザが同じテーブルおよび行を同時に使用しようとしたら、行レベル競合は問題になり得る。問題テーブルを別々の物理的テーブルへコンテキストに基づいてセグメント化することは、この型の競合を削除できることが多い。KnOSは、密度が低い行列または、行レベル競合の害を受けない。何故ならば、KnOSは行列および行をもたないからである。コンテキスト、カテゴリ化、および分類は、KnOSではリレーショナルモデルと比較して非常に異なることである。マルチパス型のタグセットコンテキスト:任意の企業データベース環境で最も困難な問題はクェリ反復であり、単一の要求が満たされる前に、何ダースもの独立した検索が要求される。このクェリ問題は、実際には本質的に連想であり、リレーショナルではない。AがFに関連するかどうかを学習するために、Bに関連することを最初に学習しなければならず、次にBがCに関連することを学習し、EがFに関連することを学習するまで同様である。A-B-C-D-E-Fは、5つの別々の連想のマルチパス複合である。これら各連想は独立しており、何としてもアプリオリであるとは決定できない。AがFに関連することを学習することは、5つの完全に独立したクェリが連続してA-B、B-C、C-D、D-EおよびE-F行われることを要求する。もし潜在的スキームが複雑なネットワーク、または階層構造即ち、マルチパスならば、この型のクェリは処理が殆ど不可能である。その様な場合、数百または数千の可能な経路に対するクェリはfansoutである。これらの型のクェリは、厳しい作業負荷問題をDBMSに示す。何故ならば、クェリの反復は並列に実施できないからである。この反復問題の最善の実世界の実施例は、BOMプロセッシングである。字下げされたBOMは部分の複雑な階層構造であり、10以上の深さレベルであることが多い。マルチレベル爆発は、lefttorightマルチパスクェリの階層的なバージョンである。それは、所定の部分の全てのchildrengrandchildren等を検索する。マルチレベル爆縮whereusedはrighttoleftマルチパスクェリの階層的なバージョン、またはネットワークのソースの方向を示すクェリであり、所定の部分アイテムの全てのparentgrandparent等を検索する。部分アイテムAが部分アイテムBの製造に使用されるかどうかまたは、その逆を学習することは、何ダースもの反復を有する複合クェリであり得る。残念なことに、そのようなクェリはユーザに非常に人気がある傾向があり、従って、製造またはネットワーク環境において高い割合のコンピュータ作業負荷を一般に示す。KnOSでは、そのような全てのクェリは、マルチパスまたは、m-p型と呼ばれる特別な型のタグセットコンテキストの使用により、単一の反復へ減少できる。上記の製造実施例では、m-p型タグセットコンテキストはマルチレベルと呼ばれる。マルチレベルタグセットコンテキストのアイテムは、BOMコンテキストのアイテムの複製であり、部分コンテキストのアイテムの複製である。新しいm-p型タグセットコンテキストの各部分アイテムに対して、parentVKセットはアイテムに対するwhereusedマルチレベル爆縮からの全部分に対するベクトルキーを含み、childVKセットはアイテムに対するマルチレベル爆発からの全部分に対するベクトルキーを含む。このm-p型タグセットコンテキストは、単一の反復の中の任意のBOM型の質問に答える。例えば、部分Aは部分BとBOM関係を有するか。AおよびBに対するKnOS参照を学習した後、アイテムAまたはBの何れかをマルチレベルコンテキストから検索すること、およびそのVKセットの1つの他のものに対するベクトルキーを含むかをチェックすることにより、このクェリは直接的に答えられる。部分Aおよび部分Bは任意の共通部分C,D,Eに任意レベルで属するかもしそうなら、どれに属するかこの表面上は単純なクェリは、リレーショナルアプリケーションでの使用のためにプログラムされていないようであることを処理する、そのような食い違う複雑さを有する。KnOSでは、クェリはマルチレベルコンテキストの単一の反復AおよびBに対するアイテムをマルチレベルコンテキストから検索し、一致のためにVKセットを比較するで単純に答えられる。もちろん、BOM階層構造例えば、BOMタグセットコンテキストへの各改訂は、全ての影響を受ける部分に対するマルチパスタグセットコンテキストのVKセットにより定義される連想を訂正するために、多数のマルチレベル爆縮および爆発を必要とする。m-p型のタグセットコンテキストを更新することは容易ではないが、基になるコンテキスト、BOMの各変更は、m-p型コンテキストでのアトミックオペレーションとして扱われ、作業負荷が許す限り処理する。各々の階層的な情報をロードまたは訂正したときに直ぐ2つのオペレーション爆縮、および爆発を行うことは、反復クェリが引き起こされる要求がある毎に2つのオペレーションを行うことよりも、DBMSに対して更に効率的である。必要な連想をこの方法で分類することにより、KnOSマルチパス型のタグセットコンテキストは、製造アプリケーションの運用効率を2桁のオーダだけ向上させることが出来る。KnOSでは、タグセットコンテキストはマルチパス型のタグセットコンテキストとして設計でき、第2の分類タグセットコンテキストに基づくことが出来る。KnOSは爆発および爆縮を基になるタグセットコンテキストで自動的に行い、マルチパス分類タグセットコンテキストを得て、オペレーションの間に同期を維持する。上記実施例のマルチレベルタグセットコンテキストは、KnOSで、KnOSにm-p型のコンテキストをBOMタグセットコンテキストに基づいて創出することを命令することにより確立される。他のアプリケーションコードは、要求されない、KnOS環境は、コンテキストの創出を担当する。次に、変化が基になるBOMコンテキストのVKセットで出現するたびに、KnOSは自動的にマルチレベルコンテキストのVKセットの同期を維持する。従って、クェリ反復は、KnOSで、マルチパスクェリに応答しなければならない任意の階層的なまたは、ネットワークコンテキストに対するマルチパス型のタグセットコンテキストを確立することだけによって削除される。KnOSは、m-p型のタグセットの維持に関連する進行中の全オペレーションを、追加のアプリケーションコード無しで処理する。マルチパス型のタグセットコンテキストは、KnOSを更にサポートする。類似の分類アプローチは、リレーショナルインプリメンテーションでは使用できない。何故ならば、リレーショナルモデルは、連想分類構造を記憶して保持する便利でコンパクトな構造をもたないからである。上記KnOSマルチレベルコンテキスト実施例の所定の部分は、数千に分解する任意の数のVKセットをもち、部分毎に1行を有する単一のリレーショナルテーブルの使用を削除する。従って、KnOSマルチパスソリューションのリレーショナルインプリメンテーションは2つの列を有するテーブルであり、テーブルの各行がマルチレベルコンテキストのVKセットを模倣する。簡単に言うと、リレーショナルソリューションは、テーブルに収納された多量のfreevectorを使用する標準的な連想スキームである。並列ベクトルプロセッサなしでは、このテーブルは処理が遅すぎて反復問題の大きな助けにならない。ビューのリレーショナル調整技術は、マルチパス問題を解決するために使用できない。何故ならば、リレーショナルDBMSは、十分なビューを1度に管理して問題を解決できないからである。単一のリレーショナルビューは、本質的に予想されたクェリの結果である。もしリレーショナルインプリメンテーションが潜在的な各マルチパスクェリそれは、本質的に、どのKnOSが行うかに対する1つのビューで確立されたら、リレーショナルプロセッサはビュー保守オーバーヘッドを処理できない。要約すると、複雑なマルチパス構造階層構造でもネットワークでもにクェリを出すことにより起こる反復問題は、リレーショナルモデル、または標準的なfreevector連想モデルの内部で解決できない。KnOSは、劇的な向上を、DBMS効率において2つの技術により達成する。リレーショナル結合のKnOS等価物は、処理が著しく単純であり、マルチパスタグセットコンテキストはクェリ反復を複雑なネットワークまたは階層上で削除するために使用できる。これら2つの問題は、従来のDBMSの殆どの性能問題の原因となる。複合タグセットコンテキスト:タグセットの最終カテゴリは、複合と呼ばれる。アプリケーションを定義することに対して広く有用な複合タグセットは、多くの異なる方法で異なる目的のために形成できる。複合タグセットは、以下のものから成る。ベースコンテキストの完全なクローン例えば、辞書コンテキストはクローンを作ることが出来る。ベースコンテキストの完全なクローン-VKセット。コンテキストの任意の組合せから選択された、1組の完全にクローンを作られたアイテム。コンテキストの任意の組合せから選択された、1組のクローンを作られたアイテム-VKセット例えば、ビューモデル。複合タグセットコンテキストの内部のクローン複製は、タグセットの型に基づくKnOS申し込みサービスにより自動的に維持される。以下の実施例は、4複合タグセットコンテキストの使用を示す。アプリケーションの創出は、ユーザインターフェースが定義されることを必要とし、ユーザインターフェースはビューモデル化として参照されることが多い。ビューモデル化では、一般にデータ関係の特定のビューを構築するために必要な参照の収集は、1つより多いコンテキストからである。もしビューを構築して特定のユーザの必要性をサポートしたければ、そのビューの全表示要素はアイテムとして複合タグセットで表現できる。そのタグセットの表示要素の中の連想は、その特定のビューに対して固有であり、従って、そのビューのコンテキストに属するとして見ることが出来る。そのビューは、複合タグセットであり得る。そのアイテムは、ベースアイテムが存在する任意のコンテキストから得ることが出来る。コンテキストのアイテム例えば、WebDisplayElementsWebPageManufacturersPartAssembliesおよびConsumerItemは異なるコンテキストから得ることができ、複合タグセットに以下の方法で追加される。新しいウェブページが創出され、WebPageコンテキストに追加される。新しいウェブページはコンテナから読み取られ、新しい複合タグセットを新しいウェブページと同じ名前で創出するために使用される。選択された表示要素はWebDisplayElementコンテキストから読み取られ、代表として、新しいウェブページタグセットにコピーされる。この実施例について更に詳細には、KnOSレイヤを参照のこと。データモデル化では、標準的なタグセットとして、複数のコンテキストを所定のアイテムに対して定義することが重要であることが多い。数ダースが存在するBOMおよび部分の実施例を所定の部分を使用し保持する数百または数千の製造されたアイテムにBOM階層構造の任意レベルで拡張するために、別個の複合タグセットが各々および全ての製造されたアイテムに対して創出され、属しているときはいつでも、多くの異なる部分コンテキストからの部分が追加できる。任意の部分コンテキスト例えば、特定の製造業者からの任意の個別部分は、その階層構造に属しているときはいつでも、全ての製造されたアイテムのBOMタグセット階層構造に追加できる。部分の中には例えば、ワッシャまたはネジ、殆ど何処でも全ての階層構造で出現するものもある。コンテキストおよびスケール:タグセットコンテキストが1つの環境またはリポジトリE/Rで創出され、地理的に表示されたKnOSインプリメンテーションの中のコンテキストを向上させることが出来る、例えば、環境11000および環境22000のユーザは、KnOSを同じアプリケーション上で実施するときでさえ、どちらかといえば比較的独立したコンテキストを創出する。換言すれば、1000の僅かなVKセットが、環境22000のアイテムに対するベクトルキーを保持し、逆も同様である。これは、インプリメンテーションを実施しているユーザが、異なる環境のコンテキストに気付かず、大体は、それらに興味を持たないからである。同じ特徴が、リポジトリにも同様に当てはまる。環境1の内部で、リポジトリ11100のユーザは、リポジトリ21200とは異なるコンテキストを有する。1つのKnOSE/Rは、コンテキストまたはアイテムに対するタグセットコンテキストを、独立に、異なるE/Rで呼び出すことが出来る。異なる規則は、E/R境界全体で呼び出されるタグセットコンテキストに当てはまる。E/Rを横断するタグセットは、3つのレベルmaintainednonmaintainedまたはlocalizedの何れかで呼び出される。所定のリポジトリの内部の標準的なタグセットコンテキストは、常にmaintainedされる。もしタグセットコンテキストがmaintainedなら、連想は基になるコンテキストに遅れないでまたは、同期して自動的に保持される。所定のE/Rの内部では、タグセットコンテキストは他のタグセットコンテキストから創出できないが、異なるE/Rの間では、標準的なコンテキストおよびタグセットコンテキストの両方が複製されて共有される。1つのE/Rからの分類または分類法のコピーは複製されて、他の内部に配置できる。これは、加入者のE/Rのコンピューティングスーツにタグセットコンテキストを局所的に調べる機能を与え、それにより局所的なKnOSサポートウィンドウを異なるE/Rの間に提供する。もしnonmaintainedのタグセットコンテキストが、1つのE/Rで異なるE/Rのコンテキストに基づいて創出されたら、E/R例えば、20002300を使用することは、加入者として発行者のホストコンテキストで確立される。そのようなnonmaintainedタグセットコンテキストはスナップショットであり、それが創出されたときだけ正確である。スナップショットを更新するために、加入者E/Rのアプリケーションは更新を要求するか、または更新要求を予定しなければならず、その時点で、加入者E/Rが新しいバージョンを発行者E/Rから要求する。加入者が新しいタグセットコンテキストバージョンを発行者から受け取るとき、それはスナップショットに取って代わる。もしタグセットが、E/R全体にmaintained基準に基づいて創出されたら、ホストコンテキストが更新されるときはいつも、更新のコピーが加入者のリストに放送され、複製が同期され続けることを可能にする。これら発行者/加入者アクティビティは、KnOS環境から直接的に呼び出される。KnOSは多次元参照に一般的な形式で構築されるので、E/Rの間の参照は、比較的単純明快なアクティビティである。E/Rの間のリンクまたはポータルは、オペレーションのルーチン部分として創出および削除できる。もしタグセットが、環境全体にlocalized基準に基づいて創出されたら、最初にlocalビューに表されるアイテムは、localizedされてlocalタグセットで表現された他のアイテムを参照するVKセットだけをもつ。他の環境のアイテムを代表するlocalizedを創出することは反復プロセスであり得るか、またはブロックとして行われる。localizingアイテムに対する主要な理由は、それらのソース環境連想からそれらアイテム別個に対する局所的なコンテキスト的連想を創出するためであり、全てのlocalizationsを大域的に関連付けるためにベースアイテムとの関係をまだ維持する。BOMおよび部分の実施例を更に拡張するために、消費財の製造は多数の設備を多数の国に有すると想定する。同じ消費アイテムの製造に使用される部品の中には異なるロケーションの異なる製造業者からのものがあり、従って異なる部品はlocalizedタグセットに取って代わる。また、localizedBOMタグセットはそれらの連想では完全に別個であるが、同じ部品アイテムを同じ階層的な位置にまだ有する。同じ部品が、全ての国の異なる配給元をもってもよい。その値付けは局所的な流通およびリードタイムであり、大口割引しきい値、および最低量は全て、各ロケーションに対して異なる。この場合、たとえ部分および階層がE/R全体で同じでも、localizedタグセットは、異なるVKセットをBOMの各部分に対して有する。KnOSレイヤKnOSは100階層化されており、完全に自己参照環境である。自己参照は、KnOSアプリケーションの全構成要素が標準的なアイテム、コンテキスト、リポジトリ、および環境のデータベースに記憶されることを意味する。これは、全てのソフトウェア呼び出し可能な機能、データベースAPI、ソースコード、等を含む。WebフォームでさえJavaServerPagesまたはActiveServerPagesとして記憶されないが、他の任意のKnOS特徴と丁度同じ様に、むしろコンテキスト、アイテム、およびVKセットを使用して定義される。ウェブページ上のボタン、および他のアクティブ特性は、KnOSベクトルキーを含み、URLは含まない。Webフォームをブラウザに対してパッケージする前に、KnOSソフトウェアはKnOSページ記述をHTMLに変換する。これは、Webコンピューティングのための標準的な環境例えば、SunMicrosystems社のJava商標登録standardJava2EnterpriseEdition商標登録またはJ2EE商標登録と比較して、本当に無構造の環境である。J2EEでは、無数のJavaclasseが、ウェブアプリケーションサーバスペースから呼び出されなければならない。ウェブアプリケーションサーバは、高いトランザクション値に応答するために、垂直方向大きなプロセッサおよび水平方向多くのサーバの両方に堅固でなければならない。対照的に、KnOS構成要素は、性能が必要になれば、ネットワークコンピューティングスタックの何処でも動作できる。例えば、アプリケーション自体、および関連するウェブページ構成は、クライアントのPC、ウェブアプリケーションサーバ、またはデータベースサーバで動作できる。KnOSコンピューティング構成要素の実行ロケーションは、アプリケーションの必要性、および提供されるハードウェアの量にだけ依存する。インプリメンテーションにおける柔軟性、および最適化された性能に加えて、この設計は、KnOSが、基本的なディレクトリ構造およびアプリケーション要素の配置を定義するためにHyperTextTransportProtocolHTTPUniformResourceLocatorURLに依存しないことを意味する。JSP/ASPが使用されるとき、ファイルシステム中のそれらのロケーションは、非常に容易に無秩序になる。各開発者が何処にそれらを配置するかを選ぶことに依存して、異なるディレクトリに記憶された同じページまたは、コードの多くのバージョンが存在する。アプリケーションに対する修正が行われるときはいつも、HTTPおよびコードの派生インスタンスのトラックを失い、単純にそれらを逃がすことは非常に容易であり、矛盾を導入し、追跡して訂正することが極めて困難な問題を起こす。KnOSに関して、データベースでは、ページ定義、およびそれらの派生的バージョンが1カ所に存在し、アプリケーションが動作している間に変更できる。KnOSウェブページの各構成部分が、アイテムおよびVKセットを使用してKnOSデータベースで別々に定義されるので、これは可能である。ページ構成要素アイテムまたは、アイテムを変更することは、1または複数のアイテムを使用する全ウェブページを自動的に変更する。企業スケーラビリティ:KnOSアーキテクチャは、企業スケーラビリティに対する性能エンベロープを定義する。ファイアウォールのための専用のノード。インバウンドHTTPディスパッチャ、セッションマネージャ、辞書マネージャ、およびデータサーバが存在しうる。リレーショナルコンピューティングモデルとは異なり、KnOSは、中間クェリ結果が各ユーザセッションでの継続性のためにセーブされることを要求しない。その結果、HTTPディスパッチは単純稼働率/作業負荷駆動であり、プーリング専用のプロセッサの数であり、フィルタリングおよびXMLパッケージングは、並列ユーザセッションの増加を処理する必要に応じて拡張できる。KnOSデータベースオペレーションは非常に効率的で予測可能なので、並列ユーザの追加の数にサービスするために追加のコンピューティング能力が一般に要求されない。しかし、更に多数の並列セッションにサービスするため、またはテラバイトの範囲を測定するディスクファームにサービスするための何れかのために、データベースプロセッサの数は、緩やかに結合されたクラスタアーキテクチャ全体に拡張できる。企業アーキテクチャ:図21KnOSスケーラビリティは、如何にして一般的な最高仕様のサイトが、最悪の仮定の元で形成されるかを図示する。高速バスにより相互接続された緩やかに結合されたプロセッシングノードの範囲である。HTTP要求が、ファイアウォールノードで受信される。もしクリアされたら、HTTP要求はHTTPディスパッチ専用のノードに転送される。サービスを提供されなければならない並列ユーザ人口のサイズ、およびプーリング、フィルタリング、およびXMLパッケージングで特定のアプリケーションによりもたらされる困難の程度に依存して、kウェブアプリケーションサーバが存在し、各々は多数のプロセッサを有する。この実施例は、2つのリポジトリが辞書専用であり、1120がシステムに維持される1110の複製タグセットであることを示す。最後に、データベースサービス専用の3つのnリポジトリが存在する。各データベースサーバは100GB以上を管理するか、または非冗長データを管理する。通常は、アプリケーションは、データベースサーバのための論理分割スキームをサポートし、ウェブアプリケーションサーバは、何のデータがどのサーバに配置されているかを知ることが出来る。この実施例は、データを論理的に分割する機能を仮定しない。いつ受信したか、またはアクセスプロファイルに関連する作業負荷に基づいて、アイテムは、3つのnデータサーバリポジトリ全体に分散する。図21に示される典型的なシナリオは、このようである。ステップ1HTTP要求がインターネットによって受信され、ファイアウォールにおいて処理される。ステップ2もし正しければ、HTTP要求は単一のディスパッチャノードに転送される。ステップ3ディスパッチャは、HTTPメッセージに埋め込まれた/暗号化されたログオン、または認証セッション証明の何れかを処理する。もし本物なら、ディスパッチャが、機能しているウェブアプリケーションサーバの中で作業負荷に基づいて要求を分ける。この場合、HTTP要求は、サービスのためにウェブアプリケーションサーバ1へ送られる。ステップ4ウェブアプリケーションサーバ1が、セッション証明およびHTTPメッセージを解析/復号化することによりセッションを確立する。ステップ5もし有効なら、HTTPメッセージは、1または複数の情報を要求する。ウェブアプリケーションサーバ1は、ASCIIサーチ要求サービスのための辞書サーバ1200に割り当てられる。ウェブアプリケーションサーバ1は、辞書サーバ1120に1組のASCII値をトランザクションから課し、ASCII変換を要求する。サーバ1120は要求されたASCII変換を行い、要求されたアイテムベクトルキーをウェブアプリケーションサーバ1上のセッションへ戻す。ステップ6ウェブアプリケーションサーバ1は要求されたアイテムベクトルキーを受信し、1組の指示されて、参照されたフェッチを、データサーバへ、各アイテムベクトルキーのリポジトリID番号に基づいて発行する。換言すれば、アイテムベクトルキーは、どのサーバが要求される各アイテムを含むかを識別する。リポジトリ11301140および11n0に対するデータサーバは、参照されたフェッチを、要求されたアイテムに対して、図21に示された方法で行う。データサーバは、要求されたアイテムを、要求しているセッションマネージャ、ウェブアプリケーションサーバ1へ戻す。ステップ7セッションマネージャは要求されたアイテムを受信し、指示されたプーリング/フィルタリングオペレーションを行い、追加データを検索する必要に応じてステップ6を繰り返す。ステップ8ウェブアプリケーションサーバは、アプリケーションコードに含まれる命令に従い、データサーバから要求される追加の任意の答えの値を検索する。ステップ9ウェブアプリケーションサーバはウェブページをレンダーし、XMLをパッケージし、セッション証明を暗号化し、HTTP応答を構成し、それをHTTPディスパッチャに戻す。現時点で、セッションは完了し、ウェブアプリケーションサーバから消される。リクエスタに戻すために、HTTPディスパッチャは、HTTP応答を、インターネットへ、ファイアウォールを通してディスパッチする。KnOSアーキテクチャは100並列なので、リレーショナル選択オペレーションステップ6の等価物は、リレーショナル結合に対する等価物から分離できる。RDBMSの中心的ボトルネックである結合オペレーションプーリング/フィルタリングのKnOS等価物は、コンピューティングスタックデータベースプロセッサ、ウェブアプリケーションサーバ、またはデスクトップの任意のレイヤで実行できる。これは、プーリング/フィルタリングオペレーション結合のKnOS等価物を呼び出す前に、選択で得られたアイテムを指定された処理ロケーションへ単純に渡すことにより行われる。図21の場合、プーリング/フィルタリングオペレーションは、ウェブアプリケーションサーバに委ねられてきた。各アイテムはプリミティブレベルの細分性で完全にカプセル化されるので、データファームは、任意の数のデータサーバ全体に、競合を増加させることなく広がることが出来る。また、ディスク配置の連続の必要性がないので、アイテムは、データサーバ全体に、作業負荷を平衡させる要求プロファイルに基づいて配置できる。辞書サーバ1120は、KnOS申し込みサービスにより維持された複製を有する1110の複製されたタグセットである。作業負荷を平衡させる任意の数の辞書サーバが存在する。これは、プロセッシングノードの緩やかに結合されたクラスタである。ノードの間の共有メモリに対する要求は存在しない。連携処理に対する全ての要求は、単純な参照されたフェッチに厳密に基づく。従って、高速バス上の全トラフィックは、HTTPまたは参照されたフェッチの何れかである。全データは、データサーバに収納された1または複数のアイテムに埋め込まれる補助データリポジトリは存在しない。全ての重要なサーバ例えば、ウェブアプリケーションサーバ、辞書サーバ、およびデータサーバは、作業負荷を満たす必要に応じて拡張できる。容易に拡張できない唯一の競合するリソースは、メインバスである。KnOSアーキテクチャは、単一の環境の内部で企業コンピューティングの必要を満たす並列処理技術を使用してスケールでき、しかもスケーラビリティはインストレーションの寿命全体を通して当てはまる。複数のKnOS環境が、類似の連動基準で機能できる。連想オペレーションのスケーラビリティ:KnOSデータベースプロセッサは、本質的に100の稼働率をプロセッサから得ることが出来る。何故ならば、KnOSデータベースオペレーションは、カプセル化された整数演算だけを使用するからである。例えば、プーリングと呼ばれる基本的な連想オペレーションを考える。基本的なプーリングオペレーションは、2つの異なるアイテムに対するVKセットの2つの完全にカプセル化された分類を取り、ベクトルキーの2つの配列の間の論理積一般に、ブール論理積演算を決定する。例えば、VKセットのchild分類をアイテムAから選択し、VKセットのparent分類をアイテムBから選択する。基本的なプーリングオペレーションを2つの配列で行うことは、AのchildrenまたはBのparentsを、オリエンテーションに依存して決定する。従って、オペレーションは、所定のコンテキストこの場合にはコンテキストparentchildに対する2つのアイテムの間の関連の完全な範囲を識別し、これが連想DBMSのコアオペレーションである理由である。各アイテムに対して、KnOSの好ましい実施例は、VKセットを正しい順序で各ベクトルキー次元の内部に維持する。例えば、parentの分類の内部で、ベクトルキー0324は0314の後に来るが、記憶媒体では0327の前に来る。基本的なプーリングオペレーションはこの方法で配置されたベクトルキーの2つの配列を比較し、2つのアイテムのVKセットの論理積を決定する。以下の議論は、単一のアイテム上のVKセットの単一の分類が特有のエントリから成ることを仮定する。単一のアイテムに対するVKセットの単一の分類が所定のベクトルキーの2以上のコピーを有することが可能であるが、それは以下のオペレーションの議論に対しては取るに足りない変化である。2つの参照分類がプールされ、出来るだけ少ない数のベクトルキーを有する配列がドライバ配列と呼ばれ、ベクトルキーを更に有する配列がターゲット配列と呼ばれる。ドライバ配列の一番下の例えば、0010ベクトルキーエントリで始めると、プーリングオペレーションが、合致するベクトルキーを、ターゲット配列の中で、標準的な2分木検索によって探す。もし、ベクトルキーの合致が2分木検索の結果見付かれば、ベクトルキーのコピーがソリューションセットに挿入され、VKセットの論理積を表現し、ターゲット配列の次のエントリのロケーションが、サーチの次の反復での使用のために特記される。もしターゲットの合致が見付からなければ、現在のドライバベクトルキーより少し大きいターゲット配列のエントリのロケーションが、次の反復での使用のために特記される。特記されたロケーションを先導するターゲット配列の部分は、所定のプーリングオペレーションでの継続的な2分木検索に対して無視される。何故ならば、ターゲット配列のその部分の全ベクトルキーエントリが、ドライバ配列から処理されている現在のエントリより小さいからである。これは、2分木検索を最適化する。プーリングオペレーションは、この方法で、ドライバ配列の次の各エントリを用いて、ドライバ配列の全ベクトルキーがターゲット配列に反してチェックされるまで継続する。この最適化された2分木検索は、実際には、ベクトルキーのVKセット配列は一般に長い文字列のベクトルキーを所定のコンテキストに対して保持しているという事実により、更に最適化される。従って、2分木検索は、loadandcompareオペレーションのcompare部分を、ベクトルキーのアイテム構成要素でのみ実行でき、ERCIのE,RおよびC要素を、アイテム一致が見付かったときだけチェックする。上記の方法で最適化され、各々で順序付けられたベクトルキーを有する2つのVKセット配列は、約10個の最適化された2分木検索/ドライバエントリ最初のドライバエントリに対しては更に多くの検索、後のドライバエントリに対しては更に少ない検索を平均でき、ターゲット配列の一致を検査する。各2分木検索動作は、プロセッサに対するloadandcompareオペレーションである。もし、プロセッサのパイプラインが最適化されたら、各loadandcompareオペレーションは単一のクロックサイクルで完了する。これらの優れた実施番号でさえ、複数の未解決のコンテキストを含んでいそうな多くのベクトルキーを有する単一のVKセット分類を用いてそのアイテムを識別することにより、著しく調整できる。最適性能のために、これら混合されたコンテキストの各々は、それらを分類し、次にそれらを独立したタグセットアイテムへセグメント化することにより解決されるべきである。もし、大きなVKセットが、4つの独立したタグセットにコンテキストに基づいてカプセル化されたら、プーリングオペレーションを行うために要求される時間は、プロセッサリソースの4分の1だけを消費する。これは、全KnOSデータベーストランザクションが、コンテキストセンシティブだからである。混乱したコンテキストをデータベース定義から削除することにより、KnOSは著しく小さい処理作業負荷経験して同じ結果を達成する。例えば、ジョブチャージ番号、労働カテゴリ、人間、週により労働計画を行うアプリケーションを考える。従業員10000人に対する主要な企業インプリメンテーションでは、このKnOSデータベースは40時間に関連する百万のベクトルキーを含む。もし40アイテムがこれらのベクトルキーを単一の分類スキームにもつなら、それは性能問題をもたらす。もしそうなら、人間コンテキストは40アイテムのVKセットに対して確立され、各人間は個人の40ベクトルキーから成る自身のタグセットを有する。次に、10000個の個人専用にされた各タグセットは、百万の代わりに平均して40アイテムを参照する100個のベクトルキーだけを有する。人間が既知であるデータベーストランザクションに対して、これは100001の因子だけトランザクション処理をスピードアップする。アプリケーションの実際の作業負荷プロファイルを調べることにより、VKセットはタグセットへデータベースの性能を向上させるコンテキストによりカプセル化でき、それによりオペレーションの効率を実質的に向上させる。6つの概念に基づくKnOSの非常に高いスケーラビリティプロファイルKnOSは、非常に広範な配布/並列化を、トランザクションの間の競合の著しい増加なしにサポートする。何故ならば、その完全にカプセル化する機能は、a細分性の非常に低いレベルにおけるデータ、およびb中心的連想オペレーションの両方だからである。コンピューティングリソースが利用可能な所であれば何処でも、同じ機能を実施するプロセッサ全体に、KnOS連想オペレーションは、水平方向に分配および並列化でき、垂直方向にアーキテクチャのスタックを上下させる。DBMS作業負荷の99を表す中心的ベクトルキープーリングオペレーションは、辞書サーバ、データベースサーバ、ウェブアプリケーションサーバ、またはエンドユーザのPCで実施できる。KnOS連想オペレーションは単純な整数演算であり、プロセッサの本質的に100の稼働率を達成するようにステージ化できパイプライン化できる。エンドユーザトランザクション毎に要求されるプロセッサタイムで測定されるオペレーションのKnOSの効率は、インプリメンテーションの後に訂正され、ボトルネックを削除し、各ボトルネックに対する正しいコンテキストを識別し、VKセットを専用のタグセットへコンテキストによってセグメント化する。全KnOSボトルネックは、非常に広範なまたは、混乱したコンテキストを用いてVKセットのクラスタに関連付けられる。KnOSは、ユーザセッションにおける継続性のために中間結果をセーブする必要はない。何故ならば、それは各時間にプロセスを繰り返すのに十分効率的だからである。オープンセッションを、各ユーザの中間結果を有する任意のシステムサーバ上で維持する必要がないと仮定すると、HTTPディスパッチはトランザクションを最小の作業負荷を有するサーバに向けることが出来る。最後に、各KnOSコンテキストは本質的に第2のキーインデックスなので、KnOSインプリメンテーションの作業負荷プロファイルは実施されているトランザクションの型または複雑さに依存しない。KnOSは、高度にスケーラブルである。何故ならば、データでもオペレーションでも、それは、システムリソースに対して非常に限定された競合により並列化できる、比較的小さな完全にカプセル化された構成要素へ分解できるからである。また、KnOS設計なので、トランザクションの異なる各型が、ほぼ同じ作業負荷プロファイルをプロセッサに示す。タグセットの使用によってデータベースのコンテキスト分類スキームを改良することにより、KnOSは性能調整可能であり、各トランザクションだけが、関連するコンテキストの内部でデータを調べなければならない。ファジー連想コンピューティングの発展に重要なトピックは、ファジー論理である。ファジー論理の内部で構築された容易化アプリケーションに対して、KnOSより適切な処理モデルはない。コンピュータについての多くの非難が出現する。何故ならば、一般にコンピュータは、正確な論理を使用するからである。コンピュータがPacoVerdeおよびPaulGreenを比較するとき、一致を検出しない。コンピュータが1028MorningsideWayを1028MornignsideWayと比較するとき、一致を検出しない。コンピュータがPacoVerdeが1028MorningsideWayに住んでおり、PaulGreenが1028MornignsideWayに住んでいることを指示されたとき、コンピュータは一致するパターンをまだ検出しない。殆どの人間は、これらの一致を直ぐに見付ける。データインスタンスは、スペイン語および英語において、各々同じであり、アドレスが互いに間違って綴られている。これらは、ファジー次元で一致する。換言すれば、言語の違いおよび綴り間違いを無視することにより、コンピュータはPacoVerdeおよびPaulGreenが非常に強い関連をもつことを決定できる。それらは同じデータインスタンス値を言語次元にもち、綴り間違い次元の同じアドレスに居住する。ファジー論理からの妥当な結論は、PacoVerdeおよびPaulGreenがエイリアスだということである。KnOSはセルラモデルでありRDBMSではないので、KnOSは、特定のアプリケーションにより定義される出来るだけ多くのファジー次元を収容、記憶、および検索できる。例えば、アプリケーションは、綴り間違いに対する1つのファジー次元、および言語等価物に対して他のファジー次元を確立する。次に、アプリケーションは、ファジー連想のためのKnOSに、parentchildのような正確な連想と丁度同じようにVKセットを挿入できる。アプリケーションがファジー連想を識別するとき、それらを記録できる。これらのファジーVKセットは、追加のVKセット分類としてアイテムの内部に、または別々のタグセットとしてコンテキストにより含まれる。この方法では、KnOSは次元を分離できる。正確なコンテキストでクウェリを出されるとき、KnOSはPacoVerdeとPaulGreenの間に一致を見出さない。ファジー言語次元でクウェリを出されるとき、一致を見出す。"