JP2005534121A - 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ - Google Patents

参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ Download PDF

Info

Publication number
JP2005534121A
JP2005534121A JP2004525705A JP2004525705A JP2005534121A JP 2005534121 A JP2005534121 A JP 2005534121A JP 2004525705 A JP2004525705 A JP 2004525705A JP 2004525705 A JP2004525705 A JP 2004525705A JP 2005534121 A JP2005534121 A JP 2005534121A
Authority
JP
Japan
Prior art keywords
data
encapsulated
instance
data instance
management system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2004525705A
Other languages
English (en)
Inventor
エベレット ロン
Original Assignee
エベレット ロン
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エベレット ロン filed Critical エベレット ロン
Publication of JP2005534121A publication Critical patent/JP2005534121A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

データ・インスタンス中心アーキテクチャを使用する連想データ管理および知識オペレーティング・システムであって、データ・インスタンスは一般にアトミックである。各データ・インスタンスは、その全ての関連に関して中心に位置できる。ベース構造はデータ・インスタンスをカプセル化し、フォームおよび機能において一般に同一であり、アプリケーションに依存しない。カプセル化参照は、カプセル化されたデータ・インスタンスとは独立して直接的に関係する他の全てに対する参照を含むことができる。カプセル化された参照は、各々のおよび全ての関連するデータ・インスタンスに対する一意な識別子、また各データ・インスタンスの抽象化されたロケーションを符号化する論理インデックスの両方であり得て、同じ参照キーを使用して任意のデータ・インスタンスを識別および配置することの両方を可能にする。

Description

関連出願への相互参照
本願は、2002年7月26日に出願された米国特許仮出願第60/398,843号、および2003年3月25日に出願された米国特許出願第60/457,207号に対応する優先権を主張する。
本発明は、データベース管理システム（または、ＤＢＭＳ）と一般に呼ばれるデータ管理の分野に関する。
初期のビジネス向けデータ処理アプリケーションは、類似のレコード構造に基づいて単層ファイルに集められた情報内容のレコードを含んでいた。企業の各部署は、データ量の多い職務（例えば、送り状処理、顧客への請求書発行）を独立にコンピュータ化しようとした。情報のこれら単層ファイルは個々のソフトウェア・アプリケーションの各様相に対して特に設計されるので、企業のデータの様相は思い通りに繰り返され（または、複製され）る。大規模なレベルのデータ冗長性が単層ファイルに存在し、それが情報を完全に更新することを困難にし、間違った答を与える（または、不適切な動作を行う）ソフトウェア・アプリケーションをもたらすことが多い。また、単層ファイル・コンピューティングは、部署別情報のスペクトル全体にわたるデータの企業がビューが存在しないことも意味した。各ソフトウェア・アプリケーションは、特有の物理的データ記憶設計、および物理的データ管理をアプリケーションの内部で実施するためにハードウェア製造業者により供給された基本的な装置アクセス方法を使用した。データ処理に対する単層ファイル・アプローチは極めて間違いを起こしやすく、高価であり、企業の戦略的ビューを提供しない。
この状況は、物理的データ管理を機能的ソフトウェア・アプリケーションから分離し、その唯一の目的が物理的データベース管理である独立した再利用可能なアプリケーションを創出するという共通の探究をもたらす。これらのアプリケーションが、データベース管理システム（または、ＤＢＭＳ）として知られるようになった。
企業データは単層ファイルに取り込むことが殆ど不可能な高度の構造的複雑性を有することが多いので（即ち、全ての構造的複雑性が２次元に平坦化されるので「単層」）、独立したＤＢＭＳにおける最初の試みは、階層的な（または、ネットワーク化された）「ポインタ」を有する大部分は冗長性のない情報のより小規模なレコードを使用した。これらのＤＢＭＳの中で選択するために、データが本来的に階層的であるのか、またはネットワーク化されているのかを決定する必要があった。両方のアプローチは、限定されたスケーラビリティを有することを証明した。これら、および他の理由に対して、階層的なＤＢＭＳ、およびネットワーク化されたＤＢＭＳは限定的商業的成功をもたらした。
1970年に、ＩＢＭ社の E. F. (Ted) Codd は、「データ記憶のリレーショナル・モデルおよび大規模な共用データバンクのための検索」(CODD, E. F., A Relational Model of Data for Large Shared Data Banks, Communications of the ACM 13, 6 (June, 1970), pp. 377-387, 以降は[Cod70]と称する）を出版した。データベース レコードを限定された冗長性を用いて組織化するための Ted Codd のモデルは、その基底構造が階層的であるか、またはネットワーク指向であるデータ内容を扱う理論的（数学的）モデルである。洗練され、一般的ではあるが、 Ted Codd のアプローチは1980年代初頭を通して広く採用されなかった。何故ならば、当時のメインフレーム・コンピュータは、リレーショナルＤＢＭＳ（ＲＤＢＭＳ）により要求される入／出力量をサポート出来なかったからである。ハードウェア能力が1980年代を通して増加するにつれて、殆どの製造業者が Codd のＲＤＢＭＳを大規模な共用データバンクを管理するための最良の手段としてラインアップし始めた。
今日、まだ単層ファイル、および階層的な（または、ネットワークをベースにした）ＤＢＭＳで動作する数百数千のビジネス向けソフトウェア・アプリケーションが存在するが、企業データベースを管理するこれらの方法は時代遅れであると考えられている。今や、情報更新は、ＲＤＢＭＳにより実施されるオンライン・トランザクション・プロセッサ（ＯＬＴＰ）サイトの領分である。大規模な複合クェリは、 Codd のリレーショナル・モデルの名残上で動作する、データウェアハウス（ＤＷＨ）と呼ばれる専門化したアプリケーションにより次第に扱われるようになった。今日、 Ted Codd のリレーショナル・モデルは、企業コンピューティングの世界にまたがって存在する。
データベース管理機構としてのほぼ一般的な容認にもかかわらず、リレーショナル・モデルに関する非常に大きな問題が存在する。最も顕著なものは、関係定義の欠如である。リレーショナル・モデルは、ａ）如何にしてそれらが創出されたか、ｂ）データの間の種々の関係は実際はどうなのか、またはｃ）如何にして前記関係がモデルで反映されるかに関する手掛かりを殆ど含まない。リレーショナル・モデルを使用して働く殆どの専門家およびエキスパートは、意味論的コンテキストの欠如により動揺する。その結果、（Ted Codd 自身を含む (CODD, E. F., Extending the Database Relational Model to Capture More Meaning, ACM Transactions on Database Systems 4, 4 (Dec., 1979), pp. 397-434, 以降は[Cod79]と称する））多くのエキスパートは、意味論的データ・モデルを創出しようと試みてきた(HULL, R., KING, R., Semantic Database Modeling: Survey, Applications, and Research Issues, ACM Computing Surveys, Vol. 19. No. 3, (Sep., 1987) pp. 201-260, 以降は[Hull87]と称する）。例えば、1976年に Peter Chen により提起された意味論的データ・モデル(CHEN, P. P., The Entity-Relationship Model-Toward a Unified View of Data, ACM Transactions on Database Systems 1, 1 (Mar., 1976), pp. 9-36, 以降は[Che76]と称する）は、リレーショナル・モデルの意味論的コンテキストを決定する手段として、ほぼ一般に容認される。
意味論的データ・モデル（ＳＤＭ）をＤＢＭＳとして実施する多くの真剣な試みが存在した。商業市場に達するものは１つもなかった。何故ならば、一部には、それらを実施することが困難だからであり（丁度必要なオプティマイザが、困難な問題である）、一部には、それらを実際のビジネス環境で使用することが困難だからである。また、ＤＢＭＳが意味論的コンテキストを収集するほど、訂正および変更が困難になる。そのような変更は意味論が機能アプリケーションにより管理されるときよりも小さな効果を有するが、ＤＢＭＳの意味論に対する十分なサポートは非常に困難である。値に基づく（または、レコードに基づく）ＤＢＭＳを動かすことは、著しく少ないリソースを使う。なぜ意味論的データ・モデルが商業市場で更に適切に行われなかったかについての他の見解は、意味論的コンテキストは性能を向上させるために余り働かない（および、実際には性能を阻害する）ということである。ＲＤＢＭＳが性能に挑戦すると仮定したら、値に基づくＤＢＭＳへの過程で意味論的コンテキストが見出せないことは驚くべきことではない。
希な例外（例えば、 Lazy Software 社からの Sentences）により、意味論的データ・モデルはＤＢＭＳとして使用されない。人間とは異なり、コンピュータはデータの意味論的コンテキストを理解する必要がない。コンピュータは、保守および実行に対して十分であるＤＢＭＳスキーマ定義だけが必要である。もし意味論的コンテキストがコンピュータが更に効率的であるように補助したら、意味論的情報を実行システムに含む理由がある。意味論的コンテキストがリレーショナル・モデルの性能を向上させることを信じる理由は存在しない。例えば、 Peter Chen のＥ−Ｒ意味論的データ・モデル[Che76]も実施するＲＤＢＭＳは存在しない。多数の意味論的データ・モデルおよび専門化した実施技術が存在するが、企業データベースを実施する広く容認された唯一の手段（リレーショナル・モデル上で動くＲＤＢＭＳ）だけが存在する。
背景技術−リレーショナル・モデル：
（オリジナルは[Cod70]であるが、現在のコンテキストに対しては[Cod79]で定義された） Ted Codd のリレーショナル・モデルはリレーショナルＤＢＭＳの基礎であり、今日、企業システムに対する一般的な実施例である。図１に「リレーショナル・モデル」として示されるリレーショナル表現では、属性値の組合せが各タップル（主キー、またはＰＫ）を一意に識別するように、全データは属性（列）およびタップル（行）から成る２次元関係（テーブル）に収められる。そのような２次元テーブルは、リレーション（従って、用語「リレーショナル」）と呼ばれる。リレーションの残りの属性（列)（即ち、ＰＫの一部でない属性)は、リレーションの非キー（または、ＮＫ）属性と呼ばれる。ＮＫ属性が(正規化された、正規形、第３正規形、および３ＮＦ)ＰＫ属性の全体集合以外の指定されたＰＫ属性の全体集合に依存するとき、各リレーションの内部で一貫性が保証される。属性に対する許容値の範囲を定めるルックアップ・リレーションを創出することは、属性レベル一貫性を保証する。
リレーション（テーブル）は、属性識別の共通の組合せによってのみ互いに接続される。ＰＫ属性はリレーションからリレーションへ移行し、それらは外部キー(ＦＫ)として知られる。ＦＫ移行は主リレーションから始まり、主リレーションはＰＫおよび非ＦＫの唯一の属性を有するリレーションである。ＰＫの複数の属性を有するリレーションは、連想リレーションと呼ばれる。一般に情報はリレーショナル・モデルから射影および／または選択により抽出され、もたらされたリレーションをＦＫに従って結合し、最後に、トランザクションで指定された属性値制限に基づいて結果テーブルをフィルタリングする。構造化照会言語（ＳＱＬ）は、射影、選択、結合、およびフィルタリングに含まれるデータ操作を指定できる。企業データベース構造が正しい(カノニカルな、または正規化された)リレーショナル形式で捕捉されるとき、記憶されたＮＫ属性に冗長性は存在しない。
リレーショナル・モデルの最良の定義が[Cod79], Section 2, 「リレーショナル・モデル」で見出され、[Cod79]はリレーショナル・モデルとして一般に受け入れられるものを簡潔に定義する。論文（[Cod79]）の残りの部分は、データの意味を更に捕捉する拡張されたリレーショナル・モデルを提案する。 Codd の拡張されたリレーショナル・モデルは、リレーショナル・モデルを少なくとも４つの「個性」を有する更に意味論的なデータ・モデルへ移行させうとしていた。拡張されたリレーショナル・モデルは、産業界に採用されなかった。
リレーショナル・モデルの長所：
リレーショナル・モデルは、データ検索、およびデータの完全性を保証するＮＫ属性に対するデータ冗長性目標を容易にする高度に進化した構造を有する。また、リレーショナル・モデルは、論理データ表現を物理的インプリメンテーションから分離する。 データ・リポジトリは、高度に進化して広く標準化されたＳＱＬにより（例えば、[SQL92]で指定されるように）実施されるリレーショナル演算と組み合わせることが出来る。
リレーショナル・モデルの長所−アプリケーション指向構造：
リレーショナル・モデルを進化させるためのプロセスは、データ・モデルにビジネス・モデルを正確に真似させる。各リレーションは、ソフトウェア・アプリケーションにより要求されるデータの複数エンドユーザ・ビューを正確にサポートするように創出される。いったん正しいリレーショナル・タップルがリレーショナル・モデルに配置されたら、特定のユーザ・ビューに必要な属性値(インスタンス)の全てがタップルの構造の内部で直接的に包含される。追加データがアクセスまたは検索される必要はない(メモリに記憶できるルックアップ値を除く)。
リレーショナル・モデルの長所−限定されたデータ冗長性：
リレーショナル・モデルの正規(カノニカル)形は、１回より多く記憶される属性のタップルは無いことを保証する。これは、記憶されるデータの量を減少させ、非キー属性への更新が例外なく行われることを保証する長所を有する。ＲＤＢＭＳに提起される各質問は、１つの方法で答えられるべきである (複数の複製されたタップルがデータ・モデルに関与するとき、データの複製が同期しておらず、従って、質問に対する間違った答を提供する可能性が存在する)。単層ファイル・モデルからのデータ冗長性の除去は、リレーショナル・モデルの魅力的特徴の１つであった。
リレーショナル・モデルの長所−リレーショナル演算およびＳＱＬ：
リレーショナル・モデルは、モデルの要素を操作するための高度に進化したリレーショナル演算、およびリレーショナル・データ構造の役割を果たすための広く標準化されたＳＱＬを有する。
リレーショナル・モデルに関する問題：
リレーショナル・モデルに関する主な問題は、その基本的なデータ構造が高度に進化していること、およびアプリケーションに依存することである。最も単純な用語では、リレーションの「行×列」構造は対称性を欠く。種々のリレーションに結び付いた属性、ＰＫ属性の指示、ならびに相互接続ＦＫの特性および構造は、指紋が個人にとってそうであるように、所定の企業のオペレーションに特有である。ＳＱＬで書かれたリレーショナル・アプリケーション・ソフトウェアは、リレーションの構造、およびビジネス・ルールに完全に依存する。
リレーショナル・モデルの各様相はアプリケーションの多くの異なるビュー／インターフェースにマップし、ソフトウェア・アプリケーションの各ビュー／インターフェースはリレーショナル・モデルの多くの異なる様相とインターフェースする。アプリケーション・ソフトウェアとデータの表現の間のこの多対多の関係は、何れかでの小変更が他方での大きな影響を有するようにアプリケーションとデータを固く結びつける効果を有する。リレーショナル・モデルのアプリケーションに依存するデータ構造（ＡＤＤＳ）は特有で、複雑で、脆弱である(変更に対する抵抗がある)ので、リレーショナル・モデルのＡＤＤＳ特性は多くの厳しい問題をソフトウェア・アプリケーションにもたらす。
リレーショナル・モデル関連の問題−ＡＤＤＳ対リレーショナルＣＯＴＳ：
ＡＤＤＳは、汎用（ＣＯＴＳ）アプリケーション・ソフトウェアの配布および保守を非常に困難な事業案にする。各アプリケーションは（ＡＤＤＳ特有性によって）本来的に特有なので、ＣＯＴＳアプリケーションの商用配布を維持するために必要なスケールの経済性を達成することは困難である。もしデータ・モデルが潜在的ビジネス・モデルにおける変化の範囲（例えば、産業界の内部でオペレーション上のプラクティスを変えること）に適応するように更に柔軟（複雑）なら、この柔軟性のアーティファクトはアプリケーション・ソフトウェアの複雑さを比例して増加させ、増大したオペレーションの柔軟性を処理する（何故ならば、ＳＱＬがデータ構造と密接に結び付くからである）。所定のインプリメンテーションはＡＤＤＳにより引き起こされた柔軟性の小部分だけを使用するが、どのインプリメンテーションも柔軟性を完全に識別して理解できなければならない。リレーショナル方程式（柔軟性は、不必要な複雑さを暗黙に定義する）は、ＣＯＴＳソフトウェアの所定のインプリメンテーションに対して不可避である。
そのように柔軟なリレーショナル・モデル・データ構造に構築されたリレーショナル・アプリケーションは、特定の企業のビジネス・モデルの様相により引き起こされるのではなく、むしろ（競合他社のビジネス・モデルに適応するＣＯＴＳアプリケーションに含まれる）柔軟性の不必要で未使用のアーティファクトにより引き起こされるオペレーション上の困難および障害を被ることが多い。
加えて、アプリケーションおよびデータ・モデルの導出された柔軟性の未使用のアーティファクトを識別すること、理解すること、および無視することは、企業の最も有能な人的ＩＴリソース、および他の施設的リソース（例えば、データ記憶、プロセッシング、トレーニング、および文書化）を不可避的に消費する。ＣＯＴＳソフトウェア・ベンダの顧客ベースが増大し続けるにつれて、柔軟性および付随的な複雑さに対する必要性は、既存の顧客ベースがＣＯＴＳアプリケーションを拒絶し始めるまで増加する。これは、ＣＯＴＳアプリケーション・ベンダの障害をもたらすことが多い。
リレーショナル・モデルに固有のＡＤＤＳが、ＣＯＴＳアプリケーション・ソフトウェア・ベンダの（殆どとはいかないまでも）多くの倒産の根本的原因であることを述べることは正当である。［即ち、ａ）商業的継続性は広汎な柔軟性を必要とし、ｂ）ＡＤＤＳのために、（所定の顧客に対して）広汎な柔軟性は不必要な複雑さを暗黙に定義し、ｃ）絶えず増大する不必要な複雑さは、顧客にアプリケーションの使用を止めさせる。］
関連するリレーショナル・モデル問題−長いフローズン・ベースライン:
所定のリレーショナル・ソフトウェア・アプリケーションに対して、リレーションの完全な構造は、アプリケーション・ソフトウェアのコーディングが始まる前に知られ／定義されなければならない。従って、ＡＤＤＳのために、リレーショナル製作者が（何年もの間測定されたフローズン要求ベースラインを必要とする複雑なデータ構造を有する企業には珍しくない）企業のデータ構造の詳細を確認して記録を取れるように、長いフローズン要求ベースラインが必要である。複雑さが極端なので、データ・モデルを要約書アイテムへ最初に記述するために意味論的データ・モデルを使用する必要がある。企業の潜在的データ・モデルがフローズン・ベースラインの期間に（時には相当に）変化するので、一般にリレーショナル・アプリケーション・ソフトウェアは、真の企業モデルに相当程度劣ることが多い。
関連するリレーショナル・モデル問題−変化への抵抗：
ＡＤＤＳおよびＳＱＬとの密接な結び付きのために、リレーショナル・ソフトウェア・アプリケーションは、リレーションの構造における最小の変化に対してさえ非常に抵抗する。この領域における最も微妙な問題は、主リレーションの単一のＰＫ属性における変化と関連する。主リレーションに対する所定のＰＫは移行して、企業のリレーショナル・モデルの内部の相当数のリレーションでＦＫになることが出来る。そのようなＰＫ属性における任意の変化は、リレーショナル・モデル、および関連するアプリケーション・ソフトウェアを通して変化を引き起こす。これは、小変更を行うことは非常に高価であり、必要な変更は高価な次善策を用いて回避されることが多いことを暗示する（何故ならば、問題をアプリケーションで訂正するためのコストが更に大きいので）。ＡＤＤＳおよびＦＫ移行の直接的な結果として、一般にリレーショナル・アプリケーションは長年適用されていないアプリケーション変更要求をバックログに有する。これが、リレーショナル・モデルに基づくＣＯＴＳ企業アプリケーションが、顧客の要望に対する程度の低い適合を一般に有する理由である。
関連するリレーショナル・モデル問題−構造的劣化：
典型的な企業アプリケーションでは、ＲＤＢＭＳは情報の基本的なテーブル形式の編成に関連する物理的再編成問題に直面する。（ＡＤＤＳに付随する）問題は、リレーショナル情報が、記憶媒体上で（物理的に隣接しないまでも）少なくともクラスタ化されるべき高度に組織化された形式で記憶されることである。しかし、最初にロード（または、リロード）されるとき、テーブルは、初期状態の構造的形式で記憶媒体上に表示されるだけである。行が削除されて挿入されるとき、このクラスタ化された物理的配置はディスク上で維持できない。時間が経過するにつれて、リレーショナル・モデルの構造化されたデータ記憶への依存のために、ＲＤＢＭＳは処理能力効率の相当部分を次第に次第に失う。企業はこの効率の損失を単に受け入れるか、物理的記憶媒体上のテーブルを定期的に再編成することにより訂正するだけである。
構造的劣化の問題は、リレーショナル・データ管理に固有のものである。複雑な物理的データ構造への依存が問題である。全ての複雑な物理的データ記憶構造は、時間が経つにつれて劣化する。ＤＢＭＳが編成のための物理的構造に依存するとき、プロセッシング効率は物理的構造のエラーに比例して劣化する。
関連するリレーショナル・モデル問題−非正規化の必要性：
正規化は、リレーショナル・モデルのキーとなる理論的長所と考えられる。実際には、モデルの大きな短所の１つである。それは、完全正規化に関する非効率を許容できるリレーショナル・モデルの珍しいインプリメンテーションである。結合オペレーションは極めて非効率で、正規化の程度が大きいほど多くの結合が行われなければならない。リレーショナル・モデルの構造を非正規化することはオペレーションの効率を提供するが、更新例外、およびオペレーションをサポートするために組み合わせられなければならない著しく冗長なデータをもたらす。これは、レコードのコピーと同期して更新されるデータ複製を維持するために必要なとき特に真である。この複雑さの全ては、アプリケーションに追加されなければならない。複雑なクェリは多くの結合を必要とするので、リレーショナル・モデル上のデータベースは、複合クェリを更にサポートするだけのために非正規化されなければならないことが多い。更新プロセッサ（ＯＬＴＰ）が複合クェリに必要な追加された冗長性（非正規化）をサポートできないとき、複合クェリをサポートするだけのための別々のＤＷＨサイトを配置する必要があることが多い。
関連するリレーショナル・モデル問題−基本的セキュリティ：
企業アプリケーションのセキュリティ要求は予測が困難である。顧客は、（データにアクセスするための）セキュリティ分類が行または列（属性）レベルであることを要求することが多い。場合によっては、顧客は、セキュリティがテーブル（行×列）の「セル」レベルであることを要求する。セキュリティ・ラベルを（確かに効率的なものはない）２次元テーブル構造の内部で実施する実用的方法は存在しない。これは、セキュリティが、２次元テーブルセルに対して実際には異なる３番目の次元だからである。特定の「行−列」組合せ（２次元）はセキュリティを必要としないか、１または複数のセキュリティ・ラベルを必要とする。もしセキュリティ次元が（リレーショナル・モデルに要求されるように）２次元テーブルに折り畳まれる（畳み込まれる）なら、結果は良くない。
これは、導出された柔軟性がリレーショナル・モデルを受け入れられなくする１領域の実施例である。アプリケーションを広く有用にするために、潜在的データ・モデルはセル−レベル・セキュリティを可能にしなければならない。更に、セル−レベル・セキュリティは、いくつかのインスタンスで呼び出されるだけである。厳密なリレーショナル・テーブル構造は、セキュリティ・ラベルを全てのインスタンス（セル）上で操作するように構築されなければならない。このアプローチは、非常に非効率である。１つの代替的可能性は、追加的テーブル構造（カテゴリ・リレーション）をセキュリティ・ラベルを必要とする「行−列」値だけを用いて創出することである。セキュアなモードでは、これがトランザクションを処理するために必要な読み取りの回数を倍にする。
アプリケーション（例えば、セキュリティ）に存在する複雑さの次元がますます増えると、アプリケーションを２次元リレーショナル記述で実施することがますます困難になる。
関連するリレーショナル・モデル問題−インターフェース出来ないこと：
ＡＤＤＳのために、情報をリレーショナル・リポジトリで読み取る能力は、リポジトリが設立されたアプリケーションに効果的に制限される。リレーショナル・モデルに対する Codd の元々の意図は大規模な共用データバンクへのアクセスを容易にすることであったので[Cod70]、これは皮肉である。異なるアプリケーションのために／により設立されたリレーショナル・データベースを共用するため、およびそのデータを効果的に使用するために、ソフトウェア・アプリケーションは「所有している」ソフトウェア・アプリケーションの複雑なＡＤＤＳを学習しなければならない。時間が経過するにつれて、各アプリケーションはビジネス・モデルおよび根底にあるＡＤＤＳを変更するので、アプリケーションのデータを共有しなければならない他のアプリケーション全てが単純に変更されてペースを維持する。この理由のために、相互接続リレーショナル・アプリケーションのタペストリにおいて１小変更を行うことさえ、岩を静かな池に投げ込むようなものである。変化の波は、相互接続アプリケーションを通して伝搬しなければならない。これは、甚大な影響をリレーショナル・アプリケーションの構造および構成に有する。例えば、殆どのリレーショナル・ソフトウェア・アプリケーションは、不必要な属性をリレーションから除去しない。そのような小変更を行い、全てのインターフェース・アプリケーションの構造および構成への広範囲にわたる効果を被ることよりも、もはや必要がないものを無視することの方が費用対効果が大きい。時間が経過するにつれて、リレーショナル・インプリメンテーションにおける不必要なデータ構造および属性の持続性が、追加の問題を複雑さ、記憶スペース、およびオペレーションにもたらす。
関連するリレーショナル・モデル問題−複雑な相互関係をモデル化できない：
リレーショナル・モデルは、複雑な相互関係をデータの中でモデル化するための実際の機構を有しない。最も基本的な関係は、属性の厳密な組の中でカプセル化される。他の全ての関係は、リレーションの中で繰り返されるＦＫの内部で単に「埋め込ま」れる。従って、リレーショナル・モデルは、意味論的方法ではリレーションの間の関係を定義しない。1976年、 Peter Chen [Che76] は最初の意味論的データ・モデル（エンティティ−関係モデル、または Ｅ−Ｒモデル）の１つを定義して、この問題を扱うためにリレーショナル・モデルを拡張した。ＰＫおよびＦＫの間の関係をリレーショナル・モデルにおいて定義し説明するために、Ｅ−Ｒモデルは、（エンティティの間で）「ビジネス・ルール」と名付けられる概念を基数（例えば、１：１，１：Ｍ，１：０，１：Ｍ,等）に追加する。リレーショナル・モデルおよびＥ−Ｒモデルは、殆どの人々（および、この分野の殆どのエキスパート）が１つのおよび同じデータ・モデルとしてビューする実世界で一般に混合される。[Cod79]では、 Ted Codd はこの概念を訂正し、リレーションの間の複雑な関係の定義および分類を含むように、リレーショナル・モデル意味論的データ・モデルに拡張しようとした。
要約すると、リレーショナル・モデルは、データ（最終状態記述）を表す手段、追加−挿入−削除、およびクェリ演算を呈示する。リレーショナル・モデルは、データの間に存在する複雑な相互関係を理解すること、解析すること、定義すること、設計すること、記述すること、または改良することの手段である。一般に、それを行うことは、意味論的データ・モデルを必要とし、意味論的データ・モデルは選択肢が多い（Chen のＥ−Ｒモデル [Che76]を含む）。
関連するリレーショナル・モデル問題−ＯＬＴＰ対ＤＷＨ：
大規模な（および、非常に大規模な）データベースがリレーショナル・モデルを用いて実施されるとき、クェリおよび更新トランザクションの間の競合は、厳しい性能上の困難をもたらす。一般に、不可欠な企業アプリケーションは、リアルタイムで更新が適用される必要がある。これは、オンライン・トランザクション・プロセッシング（ＯＬＴＰ）として知られる。しかし、また、企業もデータベースにクェリを出す必要があり、要求されたクェリの多くは精巧および／または複雑である。そのようなクェリを大規模なデータベースでサポートすることは、補助インデックスをＳＱＬ「select」句および「where」句で言及される各列で必要とする。これらの補助インデックスは更新の間維持されなければならないので、実質的オーバーヘッドを更新トランザクションに追加する。
結合テーブルが時間が掛かりリソースを多く必要とすると仮定すると、複雑なクェリもアクセスされなければならない物理的テーブルの数を減らすことから恩恵を受ける。一般的なアプローチは、結合の数を減らすためにテーブルを予め結合（または、非正規化）することである。殆どのＯＬＴＰサイトが性能を向上させるためにデータベースをある程度非正規化するが、複雑なクェリをサポートするにはとても足りない非正規化を行う。さらに、非正規化および補助インデックスの量が増加するにつれて、ＯＬＴＰ応答時間が明らかに悪くなる。この競合のために、大規模な（および、非常に大規模な）データベース上の複合クェリ・サポートは、データウェアハウスとして知られる別々のコンピューティング・スーツで実施されることが増加した。
ＯＬＴＰインストレーションはリアルタイム更新を最も良くサポートするように最適化され、日々の企業オペレーションの戦術的目標を満たす十分なクェリも今まで通りサポートする。ＤＷＨインプリメンテーションは無制限の複合クェリを大規模な（および、非常に大規模な）データベース上でサポートするように最適化され、更新プロセスを希に最小限混乱させ、戦略的アセスメントおよび意志決定支援と首尾一貫する。ＯＬＴＰは、戦術的必要性と最小限に首尾一貫するデータベース・テーブル（補助インデックス）の最小量の縦覧式の転置をサポートする。ＤＷＨは、複雑なクェリをサポートする効率に相当に寄与するデータベース・テーブルの最大量の縦覧式の転置をサポートする。ＯＬＴＰおよびＤＷＨ市場の現在の方向は、これら２つのコンピューティング・パラダイムを更に、および更に個別に、接近させずに駆動することである。
そのソリューションが費用対効果が大きいなら、ＯＬＴＰおよびＤＷＨをデータベースの同じコピー上で行うことには相当な長所が存在する。例えば、それはトレーニングを簡単にし、維持費を安くし、データの流通および精度を向上させ、戦略的サポートをＯＬＴＰおよびＤＷＨソリューションの両方を今日では許容できない多くの企業の手の届くところにもたらす。ＤＢＭＳ産業界が分離を必要悪と見ることは簡単である。
背景技術−意味論的データ・モデル：
上記のように、リレーショナル・モデルは、複雑な相互関係をモデル化するための機構をリレーションの内部または中の何れでも提供しない。先行する階層的なネットワーク・データ・モデルのように、リレーショナル・モデルは、値に基づく（または、レコードに基づく）モデルと呼ばれる。意味論的モデルは、データ相互関係を理解し、解析し、定義し、設計し、記述し、改良するためのツールとして最初に導入された。複雑なデータ・スキーマは意味論的ツールでモデル化され、ＲＤＢＭＳでのインプリメンテーションのためにリレーショナル・モデルに変換される。
最初に出版された意味論的データ・モデル「意味論的バイナリ・データ・モデル（ＳＢＤＭ）」は1974年に現れた（ABRIAL, J. R., Data Semantics, Data Base Management, North Holland, Amsterdam, (1974) pp. 1-59, 以降は[Abr74]と称する）。1976年には、 Peter Chen が全ての中で最も商業的に成功した意味論的データ・モデル「Ｅ−Ｒモデル[Che76]」を出版し、リレーショナル・モデルにおける意味論的コンテキストの完全な欠如を扱った。Ｅ−Ｒデータ・モデルが拡張したリレーショナル・モデルにおいて非常に成功したので、殆どのデータベース専門家が今日ではリレーショナル・モデルおよびＥ−Ｒモデルを１つの同じモデルと見なす。それらは同じではない。リレーショナル・モデルはＲＤＢＭＳにより実施され、一方、Ｅ−Ｒモデルはエンティティ−関係線図において実施される。Ｅ−Ｒモデルにより導入された「ビジネス・ルール」は、ＲＤＢＭＳにより本来はサポートされない。（中でも、 Codd 自身により開発された更にロバストな意味論的モデル[Cod79]と比較して）Ｅ−Ｒモデルの成功は、その簡素さに根ざす。
知識オペレーティング・システム（または、ＫｎＯＳ）を含む本発明に関係する意味論的データ・モデルの１つのグループ化は、２つの構成物：エンティティ・セット、およびバイナリ・リレーションとしてデータを記述するものである。これらの意味論的バイナリ・データ・モデル（例えば、[Abr74]、 BRACCHI, G., PAOLINI, P., and PELAGATTI, G., Binary Logical Associations in Data Modeling, Modeling in Data Base Management Systems. North Holland, Amerstam, (1976) pp. 125-148. 以降は[BPP76]と称する、 DEHENEFFE, C., HENNEBERT, H., and PAULUS, W., Relational model for a Data Base, ,Proceedings of the IFIP Congress, (1974) pp. 1022-1025, 以降は[DHP74]と称する、 HAINAUT, J. L., and LECHARLIER, B., An Extensible Semantic Model of Database and its Data Language, Proceedings of the IFIP Congress, (1974) pp. 1026-1030, 以降は[HaL74]と称する、 および SENKO, M. E., Information Systems: Records, Relations, Sets, Entities, and Things, Information Systems 1, 1, (1975) pp. 3-13, 以降は[Sen75]と称する）は、各バイナリ・リレーションをもしかすると多値関数の転置ペアとして扱う（図６「意味論的バイナリ・データ・モデル」を参照）。ＳＢＤＭおよび本発明は同じコア構成（もしかすると多値関数の転置ペアにおけるバイナリ・リレーションのセット）を有するが、本発明は本来的に意味論的データ・モデルではなく、その中では、関係を定義しようとしない。代わりに、本発明は、リレーショナル・モデルがＥ−Ｒモデルの最終結果を実施するのと大体同じ方法で、バイナリ・リレーションを基本的な命名されない「連想」として扱う。
要約すると、人間が意味論的コンテキストを切望し、コンピュータおよびＤＢＭＳは切望しない。ＤＢＭＳは、効率および保守容易性の恩恵だけを受ける。もし意味論的コンテキストの含有物がＤＢＭＳを効率的でないように、またはデータベース／アプリケーションを保守容易でないようにしたら、それはＤＢＭＳへの追加のための弱い候補である。残念なことに、意味論的データ・モデルは両方を行う（効率的でなく、保守容易でない）。更に多くの意味論的コンテキストをＤＢＭＳが収集するほど、ミスがあったこと（または、企業モデルが変化したこと）を発見したときに更に多くの変化が要求される。もしこれが本当でなければ、全ての商用ＲＤＢＭＳが少なくともＥ−Ｒ意味論的データ・モデル[Che76]を基本的なフレームワークに吸収する。
意味論的データ・モデルの長所：
意味論的モデルのより良い扱いの１つは、 Richard Hull および Roger King in 1987, "Semantic Database Modeling: Survey, Applications, and Research Issues" [Hull87]により生成された。意味論的データ・モデル化技術は、レコードに基づく（または、値に基づく）モデル（例えば、リレーショナル・モデル）を越える３つの主要な長所を提供する。
概念的（および、物理的）構成要素の分離の増加。リレーショナル・モデルでは、エンドユーザに利用可能なアクセス経路は、データベース・スキーマの論理構造を（１つのリレーションから他のリレーショナルへ通過するために識別子を比較することにより）直接的に模倣する傾向がある。意味論的モデルの属性は、直接的な概念的ポインタとして使用される。関係タイプの意味論的多重定義の減少。リレーショナル・モデルは、ａ）属性をリレーションの内部で関係づけることにより、およびｂ）２または３以上のリレーションの内部で同じ値を使用することによりオブジェクトの中の関係を記録するための２つの構成物だけを有する。リレーショナル・モデルが「値に基づく」と呼ばれることが多いのは、この後者の理由である。
便利な抽象化機構の有用性。意味論的モデルは、スキーマをビューしてスキーマにアクセスするための多様で便利な機構を、抽象化の異なるレベルにおいて提供する。
Peter Chen のエンティティ−関係（Ｅ−Ｒ）モデル[Che76]は、最も広く使用され最も広く認識された意味論的データ・モデルである。Ｅ−Ｒモデルは、リレーショナル・モデルを理解すること、解析すること、定義すること、設計すること、記述すること、および改良することのための標準的な意味論的データ・モデルである。
意味論的データ・モデルに関する問題：
意味論的データ・モデルはスキーマ設計に広く使用されてきたが、コンピューティング・ソリューションを実施する手段として大きな商業的成功は経験してこなかった。これには複数の理由がある。
意味論的データ・モデルの殆どは、（スキーマ設計のために使用される）インプリメンテーション・モデルではない。例えば、Ｅ−Ｒモデルは、インプリメンテーション・モデルではない。
多くの意味論的データ・モデルは、オブジェクト指向（ＯＯ）の行動的コンピューティング・パラダイムにより使用される。ＯＯは成功の欠如を被ってきた。何故なら、多くの企業データ・モデルが、広い基盤を有する（ＯＯのコアに不可欠な）明快な境界条件を維持しないからである。
多くの意味論的データ・モデルは焦点が狭い関心を有し、焦点が狭い関心はインプリメンテーション・モデルとしての商業化に余り適していない。
多くの意味論的データ・モデルは、大規模な使用法を得るには複雑過ぎる。 Codd 自身のリレーショナル・モデルへの意味論的拡張[Cod79]は、その理論的複雑さのために支持者を得なかった。非常に単純なＥ−Ｒモデルが、リレーショナル・モデルを定義することに対する標準的な意味論的データ・モデルである。
リレーショナル・モデルにおける本来の簡素さは、強力な非手続的クェリ言語（例えば、 ANSI SQL）の開発を可能にした。多くの意味論的データ・モデルはインプリメンテーションのためのリレーショナル・モデルにマップすることができ、それによりリレーショナル・モデル化の一般的なコンピューティング特性の長所を得る。その結果、多くの意味論的データ・モデルが、ＲＤＢＭＳによりリレーショナル・モデル上で実施される。
今日、意味論的データ・モデルが、インプリメンテーションのためのレコードに基づく（リレーショナル、ネットワーク、階層的）データ・モデルに取って代わるという専門家の意見は多くない。しかし、意味論的データ・モデルは、スキーマ解析および設計の分野で常に位置を占めているようである。
発明の要約：
本発明は知識運用システム（または、ＫｎＯＳ）と称し、連想的に、人間の思考と同様に機能する、データベース管理のための新しいコンピューティング・フレームワークである。ＫｎＯＳの基本的な組織的スキームはＲＤＢＭＳの転置、または<データ値 -> 関係>である。これはＫｎＯＳセルラ細分性を与え、ＫｎＯＳセルラ細分性が任意の種類のクェリに最大効率で答えることを可能にする。ＫｎＯＳはデータを企業モデルの関係によって記憶しようとせず、従って、ＫｎＯＳの物理的記憶構造は独立したアプリケーションであり、企業の関係が変化するときに変更しなくてもよい。また、データを処理するとき、ＫｎＯＳは非対称なＡＳＣＩＩ値を使用せず、むしろ完全に対称なベクトル・キー参照を使用する。
上記のように、ＫｎＯＳ設計は、レコードに基づく（リレーショナル、階層的、ネットワーク）ＤＢＭＳと関連する問題を解決する。ＫｎＯＳ発明の目的は、現世代ＤＢＭＳをリレーショナル、階層的、ネットワーク、または（ＯＬＴＰおよびＤＷＨの両方を含む）他の現在実施されているデータ・モデル上で押しのけて取って代わることである。
一般に、本発明は、ソフトウェアを１または複数のコンピュータと一緒に使用する方法により実施される。図２８に示されるように、本発明はコンピュータ・ハードウェアおよびソフトウェアを用いて実施される。図２８の実施例では、入力および出力がＫｎＯＳプロセッサに示される。次に、プロセッサが、データおよび命令を本発明と一致して操作する。図２８の実施例では、データはコンピュータ自体のメモリ、または外部メモリの何れかの内部に記憶される。本発明は単一プロセッサ上で実施されることが現在は好ましいが、本システムが（例えば、インターネットまたは他のネットワーク・システムによりリンクされたコンピュータを含む）コンピューティング環境の１または複数のコンピュータ上で利用されることは本発明の範囲である。特定のアプリケーションに対して、ソフトウェア、ハードウェア・プロセッサ、およびファームウェアを用いて本発明を利用することが記載される。図２９は、（特に、セキュリティ、ライセンス・キー管理、およびプーリング機能を含む）３つの機能を有するファームウェア・デバイスを示す。ファームウェアを使用する他の実施例は、他の機能をファームウェア部分で実施する。そのようなファームウェア／ハードウェア／ソフトウェア・システムでは、関連するソフトウェアを有するＫｎＯＳプロセッサは特定の機能に割り当てられ、一方、他の機能はファームウェアにより実施される。複数の実施例では、ファームウェアおよびプロセッサの両方が、種々のアプリケーションでデータを記憶装置（または、デバイス）に読み書きできる。図２９は３つの現在の好ましい機能をファームウェア・ブロック図で示すが、他の実施例が本発明の様相と異なるファームウェア・プロセッシングを有することも理解できる。
説明のために、以下の用語が適用される：
アプリケーション：特定の機能を実行するために使用される完全に自己完結型のプログラム。
データ・インスタンス：任意の区別可能なデータ、情報、または知識。例えば、任意のデータ、情報、または知識（例えば、任意の属性、アイテム、決定要素、キー、テーブル、列、行、フィールド、コンテナ、リポジトリ、環境、クラス型、モデル、関数、方法、オペレーション、関係、表示要素、クェリ、データ・モデル、ビュー、リポート、ユーザ・ディスプレイ・スクリーン、データ型、ファイル型、アイテム・パス、ファイル名、コンピュータ名、ＵＰＣコード、ＵＲＬ、ユーザ、接続、ステータス、品質、クラシファイア、ワード、センテンス、パラグラフ、ページ、チャプタ、ボリューム、オブジェクト、パーティション、セクタ、またはユーザが区別可能な参照）。
アトミック：その基本的な性質を破壊することなく定義によって分割できないもの。
基本的なデータ構造：データ記憶（または、データ表現パラダイム）の最小の構造的構成要素。
アイテム：（基本的なデータ構造に基づく）ＫｎＯＳデータベースの基本ユニットで、アイテムは自己参照ベクトル・キー、データ・インスタンス、および他の関連するアイテムを参照するベクトル・キー・セットをカプセル化する。
ベクトル・キー：アイテムへの多次元な特有の参照。
ベクトル・キー・セット：ベクトル・キーの配列であって、アイテムの内部にカプセル化され、参照アイテムとベクトル・キー・セットのベクトル・キーに参照される全てのアイテムの間の特定タイプの関連を示す。
論理アドレス：アイテムの抽象的ロケーションであって、実際の物理的ロケーションとは独立している。
論理インデックス：実際の物理的ロケーションとは対照的にアイテムの抽象的ロケーションを直接的に参照するトークン（または、値）。
ＫｎＯＳの様相の中には、既存のデータ管理パラダイム（および、技術）と一見類似しているものもあるが、ＫｎＯＳ設計はデータ管理における完全に新規の発明である。ＫｎＯＳは完全に対称なコンピューティング・フレームワークであり、--全ての値、関係、構造、およびコンテナを含み、--全てのＫｎＯＳオペレーションは、これらの対称な特性上で行われる単純なブール関数である。フォームおよび関数の１００％対称性を用いて、ＫｎＯＳはネイティブな大規模並列ベクトル・マシンとして動作できる。ＫｎＯＳは、ＫｎＯＳインプリメンテーション全体にわたり一般に認識された形式に基づくセルラ細分性のベクトル化された値の表示を使用する。これは、独立に生成された機能的アプリケーションがアプリオリな取り決め（または、構造的／スキーマ知識）なしに情報を交換できることを意味する。完全に逆転した設計および最小の構造的競合を用いて、ＫｎＯＳはリアルタイム更新および複合クェリの両方を、単一データ・コピー上において、最善のＤＷＨ製品よりも高い本来のプロセッシング効率を有する任意のコンピューティング規模で実行できる。ＫｎＯＳのコア構造はバイナリ連想構造なので、連想データベース管理システム（または、ＡＤＢＭＳ）と呼ばれる。
本発明のキーとなる差別化要因は、データ・インスタンス中心アーキテクチャに基づくことであり、データ・インスタンスは一般にアトミック（即ち、ユーザの観点からの定義により分割できない、例えば、データベースのテーブルのフィールドのデータ）であり、各データ・インスタンスは全連想の中心にあり、データ・インスタンスをカプセル化するベース構造、共通の基本的なデータ構造はフォームおよび関数において同一であり、独立したアプリケーションであって、また、他の全ての直接的に関連する独立にカプセル化されたデータ・インスタンスへのカプセル化された参照を含む。カプセル化された参照は、各々の、および全ての関連するデータ・インスタンス両方に対して特有の識別子であり、また、各データ・インスタンスの抽象化されたロケーションを完全に符号化する論理インデックスであり、任意のデータ・インスタンスを同じ参照キーを使用して識別および配置することの両方を可能にする。
データ・インスタンスに対して、エンティティをカプセル化することは「アイテム」と呼ばれる。アイテムは、データ・インスタンス、およびデータ・インスタンスと他の全ての関連するデータ・インスタンスの間の連想を定義する全ての参照をカプセル化する。アイテムは基本的なデータ構造に基づき、ベクトル・キーにより識別され、ベクトル・キーはＫｎＯＳシステムの各アイテムを一意に識別する多次元参照である。
図２７の「ＫｎＯＳ対称性」に示すように、ＫｎＯＳは最初の全面的に対称な企業コンピューティング・パラダイムである。ＫｎＯＳに対して、全ての値は他の全ての値と正確に類似し、全ての関係は他の全ての関係と正確に類似し、および全ての構造は他の全ての構造と正確に類似する。セルラ細分性と組み合わされるとき、コンピューティング・モデルにおけるこの基本的な対称性は、作業負荷を容易に細分し、オペレーションを並列廃棄しながら実行するマルチプロセッサを可能にする。例えば、ＫｎＯＳは、リレーショナル「結合」と同等の動作を有さず、必要としない。ＫｎＯＳは、全プロセッシングを、完全にベクトル化された対称な構造上での最適化された２分木（または、等価物）検索を用いて行う。セルラ細分性、基本的な対称性、およびベクトル表現の一般的使用は、プロセッサ効率を理論的限界まで最大化する。他の事柄の中で、これは、プロセッサ性能の向上がＫｎＯＳ性能の比例する向上をもたらすことを意味する。これは、任意のＲＤＢＭＳ（または、任意のＤＷＨ）アプリケーションについては当てはまらない。ＫｎＯＳ設計は、リレーショナル・モデルに内在する問題の殆どを解決する。
値対称性−任意のアトミック・データ値（即ち、データ・インスタンス、例えば「White Beans」「$9.85」「5」...）がＫｎＯＳ・ＡＤＢＭＳへ最初に挿入されるときはいつも、「ベクトル・キー」として知られるベクトル形式の大域的に特有の対称な参照値と一緒に登録される。その好ましい実施例では、ＫｎＯＳベクトル・キーは、そこに埋め込まれたロケーションの４つの次元を有する。それらは環境、リポジトリ、コンテキスト、およびアイテムと呼ばれ、ここでは{E,R,C,I}と表される。もし「White Beans」（データ・インスタンス）が「Stock」コンテキストへ「広域的」環境ドメインの「Manhattan South」リポジトリにおいて挿入されたら、「White Beans」はＫｎＯＳへベクトル・キー{E,R,C,I} = {0,6,1,3}と一緒に登録される。ベクトル・キーは、４次元的に特有の３２ビット・バイナリ整数の対称なセットとして各々が４ワードの個別ブロックで表現される。この１６バイトのベクトル・キーは、各アイテムに対するＫｎＯＳの大域的に特有の識別子である。特有の対称なコンパクトな値表現を提供することに加えて、ＫｎＯＳベクトル・キーは、情報を配置するために使用できる。（データ・インスタンス「White Beans」をカプセル化する）アイテム{0,6,1,3}は、コンピューティング環境＃０の第６のリポジトリの第１のコンテキストの第３のアイテムとして見出すことが出来る。最初にロードされるとき、全ての管理されたデータ値はこの方法で登録される。ＫｎＯＳ・ＡＤＢＭＳによる任意のＡＳＣＩＩ値の全ての他の参照（または、使用）は、これらのプロキシ・ベクトル・キーだけを参照する。図２３の「値対称性」に示されるように、この設計特性は、ＫｎＯＳの値対称性を確立する。
関係対称性−全ての関係はＫｎＯＳに１または複数のバイナリ・セグメントとして記録され、各セグメントは２つのアイテムの間の本来的な双方向関連である。デフォルトとして、ＫｎＯＳ環境はペアの双方向一貫性を自動的に維持する。もしアイテムＡがアイテムＢを指したら、アイテムＢはアイテムＡを常に指す。ＫｎＯＳ連想は本来的に命名されないが、その代わり、値に基づき、効率を向上させるために分類できる（意味論的分類は、ＫｎＯＳ調整技術である）。ＫｎＯＳアイテム意味論的過負荷を被り、アプリケーションが連想コンテキストの中で識別できるときはいつも、ＫｎＯＳが種々の連想をコンテキストにより記憶する。これは正しい連想を識別するために必要なＩ／Ｏを減少させ、正しい連想は性能を向上させる。バイナリ連想の双方向ペアを使用して関係を記憶し検索するための技術は、完全に対称である。図２４「関係対称性」は、もしベクトル・キー{0,6,1,3}により「White Beans」と識別された「Stock」アイテムが、ベクトル・キー{0,6,2,3}により「$13.45」と識別された「Price」アイテムに関連したら、「Stock」および「Price」の関係は（「White Beans」 is-price-of 「$13.45」として）本来的に対称なであることを示す。もし「Stock」テーブルの「Price」列が第２のインデックスを有するなら、（リレーショナル・モデルのタップルとして表現される）同じ関連は対称なだけであることを銘記する。加えて、全てのＫｎＯＳ関係が連想の内部、および全体の両方で対称に表現され、リレーショナル・モデルの関係がタップル、および外部キー（または、ＦＫ）の両方を用いて表現され、外部キー（または、ＦＫ）は内部および全体表現の両方で非対称である。
構造的対称性−バイナリ連想の各双方向ペアのターゲット・ベクトル・キーは、サブジェクト・データ・インスタンスにより完全にカプセル化されて記憶される。もし「White Beans」（サブジェクト）が「$13.45」（ターゲット）の値段を有する（関係）なら、ターゲットの合計金額を保持するアイテムがＫｎＯＳに{E,R,C,I} = {0,6,2,3}として登録される。サブジェクト・アイテム{0,6,1,3}（「White Beans」）は、（「$13.45」に対して）ターゲット・アイテム {0,6,2,3}によりカプセル化され、逆の場合も同様である。図２５「構造的対称性」−ＫｎＯＳアイテムに示されるように、各アイテムに対するカプセル化された参照の（これらの型に分類される）セットは１次元配列の順に記憶され、コンテキスト型によりベクトル・キー・セット（ＶＫセット）と呼ばれる。全てのアイテムは、同じ完全に対称なデータベース構造−ａ）自己参照（ベクトル・キー）、ｂ）データ・インスタンス、ｃ）（ＶＫセット として表現される）関係、およびｄ）（オプションとして）１または複数のアイテム埋込要素（ＩＥＥ）を有する。また、図２６「構造的対称性」−ＫｎＯＳコンテキストに示されるように、（全てのカプセル化されたターゲット参照を有する）ＫｎＯＳアイテム構造も型により分類され、分類されたコンテキスト（例えば、１つのコンテキストでは「Stock」、および他のコンテキストでは「Price」）に記憶される。各コンテキストは他の全てのＫｎＯＳコンテキストと同じ構造を有し、これはＫｎＯＳコンテキストが完全であることを意味する。従来技術のシステムと比較して、ＫｎＯＳシステムの多くの長所が存在する。これらの差異および長所が、以下に要約される。
以下が、本発明の実施例の長所および目的を概説する。
ＣＯＴＳアプリケーション：ＫｎＯＳアイテムはセルラであり、ＫｎＯＳコンテキストは完全に独立して１００％対称なので、ＫｎＯＳデータベースはアプリケーション依存的ではない。この独立性は、考えられる最も広いスケールで持続する。企業リソース計画アプリケーションのＫｎＯＳスキーマは、地理情報システムと同じ形式および構造を有する。ＫｎＯＳコンテキストは、他の任意のコンテキストの構造への影響なしに、およびソフトウェアへの予測不能なまたは連鎖的な影響なしに組み込みまたは排除できる。どの様な型のアプリケーションが実施されているかに関係なく、ＫｎＯＳデータベースは正確に同じ方法で記憶され、アクセスされ、処理される。アプリケーションは、一度にローカルで最も利用可能な知識だけを用いて１つのコンテキストを構築できる。いったん定義されたら、各コンテキストは、そのコンテキストが拡張されるときに、その構造を決して変えることなく更新できる。ＣＯＴＳソフトウェア・アプリケーションは１つの（または、多くの）産業界モデルに対して準備され、場合場合によって、ＲＤＢＭＳと関連するＣＯＴＳアプリケーション問題に基づくことなく実施される。
非フローズン要求ベースライン：ＫｎＯＳはアイテム毎に、コンテキスト毎に、およびリポジトリ毎に、迅速なアプリケーション開発（または、結合アプリケーション開発技術）を使用して実施できる。開発を開始してソフトウェア機能を提供するに当たり、ＫｎＯＳ設計の長所により、開発者は値の形式、関係の特性、データベースの全体構造、またはアプリケーションの設計でさえ理解する必要がない。ＫｎＯＳの１００％対称なセルラ技術は、開発のために非フローズン要求ベースラインを必要とする。
変化に対する非抵抗：インプリメンテーションのための非フローズン・ベースライン要求を踏まえて、ＫｎＯＳの柔軟なインクリメンタル特性は、アプリケーションが局部的条件を越える影響を与えることなく局部的変化に対して連続的に調整できることを暗示する。例えば、テーブル列の等価物は、アプリケーションが走っている間に影響なしに追加または削除できる。
構造的再編成に対する不必要性：ＫｎＯＳの潜在的データ・リポジトリは、時間が経つにつれて劣化するテーブル構造では編成されない。ＫｎＯＳの内部の挿入、編集、および削除作業は、ＫｎＯＳオペレーションの効率に強い影響をもたない。ＫｎＯＳコンテキストの内部のアイテムは、本来的に順次的、またはクラスタ依存的ではない。ＫｎＯＳベクトル・キーは完全であり、シークエンス依存的ではない。従って、ＫｎＯＳインプリメンテーションは、効率を向上させるためにリロードまたは再編成する必要は決してない。
完全に正規化する機能：完全正規化は、データベース管理の非常に優れた方法である。何故ならば、他の事柄の中で、更新し保守しなければならないデータの量を減らす一方で、更新例外および同期エラーを除去するからである。逆に、リレーショナル・モデルの性能は、正規化の程度と反比例して劣化する。構造が正規化されるほど、ＲＤＢＭＳの性能は悪くなる。対照的に、ＫｎＯＳ設計の完全対称性は、性能が正規化の程度と直接的に比例することを意味する。完全に正規化されるとき、ＫｎＯＳ・ＡＤＢＭＳインプリメンテーションは最高性能を発揮する。
また、リレーショナル・モデルのカノニカル・フォームは、非キー属性だけの値冗長性を非常に低い（または、非常に高い）基数を用いて除去する。しかし、（高度に正規化された）テーブル構造 （値に基づく関係）は、値冗長性を除去しない。ＡＳＣＩＩ形式のＰＫ値は、リレーショナル・モデルを通して繰り返される。何故ならば、値に基づく外部キーが、関係を記録するために使用されるからである。
次元独立性−基本的セキュリティ：ＫｎＯＳは、次元独立性をセルラ細分性から引き継ぐ。テーブル・セルのＫｎＯＳ等価物は、ゼロ、ゼロ、１、または多くの値（０，１，Ｍ基数）を有する。ＫｎＯＳデータ・モデルはｎ次元であり、ｎ次元は、アプリケーションの問題（例えば、基本的セキュリティ）となる任意の次元が、必要性に応じた最善の方法で適所でモデル化されることを意味する。
アプリケーションの間のインターフェース：ＫｎＯＳコンテキストは細分性においてセルラであり全面的に対称なので、種々の インプリメンテーションがアプリオリな取り決めを種々のリレーションの構造に対して有するか有さないかに関係なく、ＫｎＯＳコンテキストはインプリメンテーションからインプリメンテーションへの類似性を比較できる。インターフェースする２つのＫｎＯＳアプリケーション・インプリメンテーションに対して、類似の関連情報を用いてコンテキストを相互参照する必要があるだけである。アプリケーション（または、サイト）の各関連において、ＫｎＯＳはこれらコンテキスト相互参照を維持できる。アプリケーションがこれら相互参照されたアイテムの１つに反するトランザクションを発行するときはいつも、ＫｎＯＳは自動的に任意のベクトル・キーを変換し、トランザクションをターゲット・サイトに対抗して発行し、受信すると直ぐに応答を変換する。この方法で、ＫｎＯＳアプリケーションはターゲット・サイトのＡＤＤＳの予備的知識なしにデータを読むことが出る。縦覧式の情報内容にアクセスして理解するために、ＡＤＤＳの全体的複雑さが理解されなければならないので、ＫｎＯＳを用いて、ターゲット・アプリケーション（または、サイト）の属性は、複雑なリレーションで束縛される。
複雑な相互関係をモデル化する機能：ＫｎＯＳはリレーショナル・モデルと比較して実質的に向上した関係コンテキストを有する。まだ値に基づくデータ・モデルであるが、ＫｎＯＳは意味論的バイナリ・データ・モデルを用いて１：１にマップされる（図２４「関係対称性」を参照）。各関連は明白には命名されないが、ＫｎＯＳのバイナリ連想は次元に関しては完全に類別でき、ベース・コンテキストに従属する別々の命名されたタグ・セットへ分離できる。経験は、４つのカプセル化された関連次元（「parent」「child」「link」および「related」）のＫｎＯＳの好ましい実施例が、所定のレベルの性能効率を達成するのに十分な意味論的コンテキストを提供することを示す。ＫｎＯＳのこれら特性は、処理能力性能を向上させる意味論的コンテキストの長所を取ることを可能にする。
好ましい実施例ではないが、ＫｎＯＳは、ＳＢＤＭに含まれる任意の意味論を失うことなく、意味論的バイナリ・データ・モデルをサポートするように容易に拡張できる。ＫｎＯＳは、関係の分類のための２つの広い選択（カプセル化、およびセグメント化）を提供する。カプセル化された関係は、アイテムの（従って、「カプセル化された」）コンテキストの内部に配置される。セグメント化された関係は、（基になるコンテキストとアイテム毎に適合する）別々の従属タグ・セット・コンテキストに配置される。カプセル化とカプセル化の区別は、性能効率の単純な１つである。何れのカテゴリでも、関係は命名できる。タグ・セットは命名されるので、タグ・セットを有する意味論的コンテキストの損失はない。次元カプセル化は、単に連想「次元」を更に追加することによる命名された（正確な意味論的コンテキストによる）分類である。
ＯＬＴＰおよびＤＷＨパラダイムの解決：コンピューティング・パラダイムをテーブル・レベルからセルラ・レベルへ変換することにより、ＫｎＯＳはリレーショナル・モデルの本来の競合の多くを除去する。ＫｎＯＳは、「行」および「列」構造のカプセル化効率を、テーブルの非対称な特性を損なうことなく使用する。その結果、ＫｎＯＳは、テーブルの非対称な構造のアプリケーションに依存する特性を損なうことなくテーブル表現を配置する能力を有する。ＫｎＯＳは、リレーショナル結合に関連する非効率なしに、完全正規化に関連する効率および精度を得た。ＫｎＯＳは本来的に完全逆転（関係が対称的）なので、ＯＬＴＰおよび複合クェリの両方を、単一のコンピューティング・パラダイム、およびデータベース・コピー上でサポートできる。ＫｎＯＳは、全ての関連する利点を有するＯＬＴＰおよびＤＷＨコンピューティング・パラダイムを再結合される。
参照一貫性の解決：相互参照テーブルに基づくデータは、リレーショナル・モデルにおける巨大な挑戦であり、進化するにつれて、システムの複雑さを管理するために更に多くの人工的なキーおよびテーブルの連続的追加を必要とする。複雑で非対称なシステムを複製されたキーで更新することは、特定キーの全インスタンスへの直接参照が存在しないので、更新の不完全さによる矛盾をもたらすことが多い。
以下は値、関係、および構造的表現のためのＫｎＯＳの対称なフレームワークの短い議論であり、リレーショナル・モデルに関連するこの問題および他の問題を克服する。ここで参照される図２２−図２６は、図１「リレーショナル・モデル」の実施例に関係する。
ＫｎＯＳに関連する追加の長所が存在する。例えば、ＫｎＯＳにより利用されるオープン・ディスク形式は、理論的可能性として本来的にセキュアである。これは、ａ）殆どのデータベース値がプロキシである、ｂ）物的接近により暗示される関連が存在しないからである。ＫｎＯＳディスク形式は、余白、またはＡＳＣＩＩビット・パターンの何れかにより定期的に割り込まれるバイナリ整数の隣接する文字列の全体から成る。ＡＳＣＩＩビット・パターンは、ＫｎＯＳを走らせることにより１２８ビット暗号化を用いて任意の永続的なＡＳＣＩＩデータ・インスタンス、および任意の埋め込まれたＡＳＣＩＩ値上で容易に隠蔽でき、これは最小の性能ペナルティで出来る。いったんそれが遂行されたら、ディスク上のＫｎＯＳデータ表現はアプリケーション自体の他によっては本来的に判読不能である。もし、好ましい実施例のように、データベースの正確な意味論的コンテキストが、データベース中ではなくアプリケーション中で維持されるなら、ＫｎＯＳの未加工データ形式からのコンテンツを識別する僅かなチャンスが本質的に除去される。意味論的ローディングの代わりにコンテキスト的分類を（即ち、ＶＫセットは分類されるが、各ＶＫセットの正確な意味論的コンテキストはデータベースに記録されない）、および１２８ビット暗号化をＡＳＣＩＩ表示で用いることにより、ディスク上の ＫｎＯＳデータ形式は、全ての実用的目的に対して、一般配列(bag-of-bits)である。
ＫｎＯＳは、任意の意味論的データ・モデルを押しのけ、または拡張しようとはしない。むしろ、ＫｎＯＳは（コンテキストにおいてバイナリ・データ・モデルに類似する）更に柔軟な連想コンピューティング・フレームワークを提供し、任意のおよび全ての企業データ・モデルを実施する。更に、ＫｎＯＳは意味論的コンテキスト（分類）を最大限使用して、最良の処理能力効率を所定の企業モデル上で達成する。即ち、ＫｎＯＳの追加の意味論を好ましい実施例の範囲を超えて収集することは、コンピューティングの全コストを増加させ、本来のセキュリティを減少させそうである。
ＫｎＯＳは、更に広い連想ＤＢＭＳを有する全ＲＤＢＭＳと取って代わろうとする。用語「連想」は、ＫｎＯＳはリレーションおよびＦＫ実施例のセット構造に限定されず、リレーショナル・モデルのように、むしろ更に強力な意味論的データ・モデルにより定義される関係コンテキストの全範囲を可能にすることを記載しようとする。セルラ細分性、およびフォームおよび関数の１００％対称性により、ＫｎＯＳ設計はデータベース管理の新しいベンチマークであり、現在の全ての値に基づく コンピューティング・パラダイムに取って代わるセルラ・コンピューティング・パラダイムである。
［図面の詳細な説明］
以下は各図面の更に詳細な説明、種々の図面の説明である。
図１「リレーショナル・モデル」は、単一の主キー（ＰＫ）属性が「Stock」である主リレーション（「Stock」）、およびＰＫが２つの外部キー（ＦＫ）属性の組合せである連想リレーション（「Stock-Orders」）（即ち、「Stock」リレーションからの「Stock」、および「Order」リレーションからの Order # ）を示す。また、図１は、如何にしてリレーショナル・モデルが射影、選択、および結合してサンプル・クェリ「全 stock order の white beans の総額はいくらか？」に答えるかを示す。
図２「「主」リレーションの同化」は、如何にしてリレーショナル・モデルの主リレーションがＫｎＯＳに同化されるかを示す。「Stock」主リレーションのタップルは、「Pinto Beans」「Kidney Beans」「White Beans」および「Wax Beans」と命名される。「Stock」コンテキストは、行関係を記録するために使用されるＫｎＯＳコンテキストの実施例である。主リレーションの他の全ての列は１つの列として各ＫｎＯＳコンテキストに同化され、この場合、「Stock」に対するコンテキスト、および「Price」に対するコンテキスト（列に類似したコンテキスト）である。
図３「「連想」リレーションの同化」は図２に示されるプロセスを示すが、連想リレーション、またはリレーションのＰＫが他のリレーションからのＦＫとして移動するリレーションは別にする。各リレーショナル列に対する１つのＫｎＯＳコンテキスト＋ Stock-Order リレーションのタップルを表現するための１つのＫｎＯＳコンテキストが存在する。
図４「行および列のＫｎＯＳコンテキストへの射影」は、「リレーション」を図１からＫｎＯＳコンテキストへ変換する第１のステップを示す。ＫｎＯＳコンテキストは１つの連想リレーション（「Stock-Order」）の行に対して創出され、 および then １つのＫｎＯＳコンテキストは両方のリレーションの各列に対して創出され、「Stock」「Price」「Order」および「Qty」に対する追加のＫｎＯＳコンテキストをもたらす。
図５「ＫｎＯＳコンテキストへの関係の同化」は、図１に示されるリレーショナル・モデル実施例の全関係のＫｎＯＳモデルへの同化を示す。
図６「意味論的バイナリ・データ・モデル」は、図１に示されるリレーショナル・モデルのための古典的な意味論的バイナリ・データ・モデルを示す。１つのＫｎＯＳコンテキストが意味論的バイナリ・データ・モデルの各ノードに対して存在する点で、ＫｎＯＳに類似している。双方向関係の各々は命名され、関連のインスタンス（即ち、多値）が左上に示される。
図７「バイナリ連想をＫｎＯＳコンテキストで表現する」は、図６に示される意味論的バイナリ・データ・モデルの単一セグメントを示す。実施例は、「Stock」エンティティと「Price」エンティティの関係を示す。関係の各要素は、「Stock」エンティティの１つの値（例えば、「Pinto Beans」）を「Price」エンティティからの適合する値と関連付ける。意味論的バイナリ・データ・モデル記述は非対称であり、一方、ＫｎＯＳ記述は対称である。
図８「データ表示の比較」は、３つの全ての表示（リレーショナル・モデル、意味論的バイナリ・データ・モデル、およびＫｎＯＳ）で示された図１のリレーショナル・モデル実施例からの未加工データを示す。下が、リレーショナル・モデルからのＡＤＤＳである。左が、意味論的バイナリ・データ・モデルとして表現された同じデータベースである。右上が、（正確なコンテキストはＶＫセットに示されていないが）同じ未加工データのＫｎＯＳ表現である。ＫｎＯＳコンテキストは、バイナリ・データ構造およびテーブル構造の両方からのデータを表現できる。
図９「アプリケーション独立性」は、何故ＫｎＯＳコンテキストが独立したアプリケーションであるかを示す。新しい属性を「Stock」リレーション（新しい列）に追加することは、リレーショナル・モデルの「Stock」エンティティの物理的構造を変える。ＫｎＯＳコンテキスト・データ・アーキテクチャを用いて、同じ変更は更にＶＫセットを「Stock」コンテキストへ単純に追加し、アイテム（または、コンテキスト）の構造は変えない。アイテムは、「Qty」属性関連が追加される前後で同じ構造を有する（即ち、{ベクトル・キー・データ・インスタンス−ＶＫセット}）。
図１０「ＫｎＯＳオペレーション」は、如何にしてＫｎＯＳがコア・オペレーションを「参照されたフェッチ」を用いて行うかを示す。この実施例は、図１のリレーショナル・モデルで呈示された問題と同じである。ＫｎＯＳは、
（１）どの stock-order が white beans のためのものかを決定する。「Stock」コンテナからのアイテム{0,6,1,3}（データ・インスタンス = 「White Beans」）をフェッチする。
（２）アイテム {0,6,1,3}から「Stock-Order」コンテナ（即ち、フォーム {0,6,3,X}のベクトル・キー）への任意のＶＫセット参照を抽出する（即ち、 {0,6,3,1} & {0,6,3,5}）。
（３）関連する量を決定する。「Stock-Order」コンテナからのアイテム {0,6,3,1} & {0,6,3,5}をフェッチし、「Qty」コンテナ（{0,6,5,X}）への任意のＶＫセット参照を抽出する。答は各々 {0,6,5,1} & {0,6,5,3} である。 {0,6,5,1} & {0,6,5,3} を「Qty」コンテナからフェッチして、答え「１」および「３」（データ・インスタンス）を各々得る。
（４） white beans の価格を決定する。アイテム {0,6,1,3} （データ・インスタンス = 「White Beans」）から 「Price」コンテナへのＶＫセット参照 （即ち、フォーム {0,6,2,X} のベクトル・キー）を抽出する（即ち、 {0,6,2,3} ）。アイテム {0,6,2,3} を「Price」コンテナからフェッチして、答え「$13.45」（データ・インスタンス）を得る。
（５）ＫｎＯＳの結果は拡張されて合計され、 $53.80 を得る。フェッチ・アイテム {E,R,C,I} は参照されたフェッチである。何故ならば、ベクトル・キー {E,R,C,I} は、特有の参照およびＫｎＯＳ論理アドレスの両方であるからである。
図１１「プーリングの実施例」は、如何にしてＫｎＯＳが質問「「Pinto Beans」のためのどの Stock-Order が Qty <= 2 である Qty を有するか？」に答えるかを示す。「プーリング」オペレーションでは、関連するアイテムがデータベースからフェッチされ、その目的が論理積を決定することである一連の直接的な整数比較のために「pool」の内部へ配置される。第１のステップは「Qty」コンテキストからデータ・インスタンス <= 2 である全アイテムを抽出し、それらを「pool」の内部に配置することである。次に、「Stock」コンテキストからデータ・インスタンス = 「Pinto Beans」であるアイテムをフェッチし、それを「pool」の内部に配置する。最後に、「Stock-Order」コンテキストからのドライバ要素（即ち、 {0,6,3,X}）を、「pool」の内部に配置する。直接的な整数比較を {E,R,C,I} の最初の３つの構成要素（この場合は {0,6,3,X}）で行う。整数比較から得た論理積 {0,6,3,2} （または、 Stock-Order 2*）が質問への答である。
図１２「多次元参照モデル」は、如何にして所定の多次元ベクトル・キー {1,38,1,5} が実世界の状況に割り当てられるかを示す。本発明の好ましい実施例では、多次元参照モデルは４つの次元を有する。世界のビュー（または、環境）は、「United States」 = #1 のように国に割り当てられる。リポジトリ・ビューは、（環境 #1 の内部で）「New York processing site」 = #38 のように、国の内部のプロセッシング・サイトへ割り当てられる。人間のアイデンティティは、 {E,R} = {1,38} の内部でコンテキスト #1 に割り当てられる。人間「Duane Nystrom」は、 {E,R,C} = {1,38,1} の内部で参照 #5 に割り当てられる。「Duane Nystrom」に対する特有の多次元参照（または、ベクトル・キー）は {1,38,1,5} である。また、「Duane Nystrom」の抽象化されたロケーションを発見するために使用されるのは論理インデックスであり、環境の中のリポジトリの中のコンテキストの中のアイテムである（詳細は図１６を参照）。
図１３「アイテムの構造」は、実際のアイテムの概念的および物理的表現を示す。物理的表現は右に図示される。アイテムは可変数のワード（各ワード＝３２ビット、または４バイト）であり、ここでは１行に４ワードの行で示される。ＶＫセットの読み取りに列は容易に使用でき、第１の列は環境次元（Ｅ）、第２の列はリポジトリ次元（Ｒ）、第３の列はコンテキスト次元（Ｃ）、および最後の列はアイテム次元（Ｉ）を表す。ここでは、このベクトル・キーは {E,R,C,I} と略記される。
図１４「双方向参照」は、ＫｎＯＳの基本的なプロパティを示す。各明示的参照は明示的逆参照を有する。ここに示されるのは、「Duane Nystrom」が「Brown」のhair colorを有する参照である。また、hair colorコンテキストの「Brown」アイテムも、「Duane Nystrom」に戻る明示的参照を含む。また、図１４は、「Duane Nystrom」から電話番号への埋込参照を示す。埋込参照に関して、逆参照能力は存在しない。
図１５「ＡＳＣＩＩ変換」は、如何にしてデータ・インスタンス「Duane Lewellyn Nystrom, Esq.」がそのＫｎＯＳベクトル・キーに変換されるかを示す。どのアイテムのデータ・インスタンス値が「Du」で始まるかを決定するために、ＡＳＣＩＩで第１および第２の文字が検索される。次に、もたらされたアイテムが、人間に対するコンテキスト {1,38,1,0} と一緒にプールされる。これは、２つの適合アイテムの論理積をもたらす。データ・インスタンス値を全適合アイテム上で比較して、答え {1,38,1,5} を得る。
図１６「アイテム {0,6,8,2} を物理的媒体に配置」は、如何にしてＫｎＯＳがベクトル・キーの値 （{E,R,C,I}） を使用してアイテムを配置するかを示す。最初に、ＫｎＯＳは、リポジトリ・コンテナから「Ｃ」値が特定の {E,R,C,I} と一致する（ベクトル・キー形式の） {C,R,N,O} ディレクトリ・エントリを検索する。この場合、 {E,R,C,I} = {0,6,8,2} がリポジトリ・ディレクトリ・エントリ {C,R,N,O} = {8,3,1,5} と一致し、リポジトリ・ディレクトリ・エントリ {C,R,N,O} = {8,3,1,5} はディスク上のコンテキスト {0,6,8,0} のロケーションを与える。次に、ＫｎＯはＳは、 {0,6,8,0} コンテキストから「Ｉ」値が特定の {E,R,C,I} と一致する（ベクトル・キー形式の） {I,R,N,O} ディレクトリ・エントリを検索する。この場合、 {E,R,C,I} = {0,6,8,2} がmatches コンテキスト・ディレクトリ・エントリ {I,R,N,O} = {2,3,6,7} と一致し、コンテキスト・ディレクトリ・エントリ {I,R,N,O} = {2,3,6,7} はディスク上のアイテム {0,6,8,2} のロケーションを与える。
図１７「リポジトリ構造」は、リポジトリ・データ構造としての基本的なデータ構造の図表である。
図１８「コンテキストおよびアイテム構造」は、コンテキストおよび アイテム・データ構造としての基本的なデータ構造の図表である。
図１９「アイテム {0,6,8,2} を物理的媒体上で更新する−Ｉ」は、もし更新されたアイテムが更新の後で以前のスペース割当に適合しなければ使用できるＫｎＯＳ更新の１つの方法を示す。更新されたアイテムは、リポジトリ・ファイルの最後に追加される。
図２０「アイテム {0,6,8,2} を物理的媒体上で更新する−ＩＩ」は、ＫｎＯＳによる物理的ディスク管理の好ましい実施例を示すことを除き、図１９と類似している。図１８と同様に、アイテム {0,6,8,2} は、ディスク上に現在配置されている１ページを大きくする更新を受信する。好ましい実施例では、ＫｎＯＳは登録のためのスペースをもたない。代わりに、ＫｎＯＳは最初に次のコンテナをファイルの終わり（この場合は {0,6,5,223}）まで移動させ、それによりアイテム {0,6,8,2} を元のロケーションへ戻すのに十分なスペースを空ける。事実上、アイテム {0,6,8,2} は、 {0,6,5,223} に対して以前に割り当てられた追加のスペースとして継承する。
図２１「ＫｎＯＳスケーラビリティ」は、如何にして一般的な最高仕様のサイトが、高速バスにより相互接続された疎結合プロセッシング・ノードの範囲として形成されるかを示す。
図２２「コンピューティング環境の間の相互参照」は、如何にして多次元ベクトル・キーをＫｎＯＳに取り入れることが、コンピューティング環境境界全体に関連する完全に切断されたデータシステムでアイテムを可能にするかを示す。
図２３「値対称性」は、如何にして非対称なＡＳＣＩＩ表示が対称なＫｎＯＳ参照に変換されるかを示す。
図２４「関係対称性」は、リレーショナル、意味論的バイナリ、およびＫｎＯＳデータ・モデルの対称性（または、その欠如）を示す。
図２５「構造的対称性−ＫｎＯＳアイテム」は、如何にして本来的に非対称なリレーショナル・モデルが対称なＫｎＯＳアイテムとして描かれるかを示す。
図２６「構造的対称性−ＫｎＯＳコンテキスト」は、如何にしてＫｎＯＳアイテムが対称なＫｎＯＳコンテキストの中でグループ化、およびカプセル化されるかを示す。
図２７「ＫｎＯＳ対称性−ＫｎＯＳコンテキスト」は、ＫｎＯＳ設計の全体的対称性（値、関係、および構造）を示す。
図２８は、システム上で動作するＫｎＯＳソフトウェアを有するコンピュータで実施されるＫｎＯＳシステムを示すブロック図である。
図２９は、データ・セキュリティ、ライセンス・キー管理、およびＫｎＯＳオペレーション・アクセラレータを取り込むファームウェアを利用するシステム上で動作するＫｎＯＳソフトウェアを有するコンピュータで実施されるＫｎＯＳシステムを示すブロック図である。
図３０は、従来技術のデータベース・システムの図表である。図３０は、図表の単一の Stock Order に関する Stock, Qty, および Order の連想を示す。リレーショナル形式および連想形式におけるデータ・モデルの相対的コンパクト性が分かる。
コンピューティング環境が、図２８−図２９に示される。システムマルチプロセッサを含む多様な方法で実施できるが、図２８は単一コンピュータ上のソフトウェア実施例を示す。図２９は、データ・セキュリティ、ライセンス・キー管理、およびＫｎＯＳオペレーション・アクセラレータを取り込むファームウェアを利用するシステム上で動作するＫｎＯＳソフトウェアを有するコンピュータで実施されるＫｎＯＳシステムを示すブロック図である。これら２つの実施例だけが示されるが、異なるハードウェア形態を使用する種々の実施例が本発明を利用できることが、当業者に理解されるであろう。本明細書は、2002年7月26日に出願された米国特許出願第60/398,843号、および2003年3月25日に出願された米国特許出願第60/457,207号を、言及することにより取り込む。
以前に概説したリレーショナル・モデル本来の問題を解決するために、リレーショナル・モデルとは逆にＫｎＯＳは構造化される。ＫｎＯＳでは、データ値は関係につながる。ＫｎＯＳの編成規則は<データ値 -> 関係>であり、<データ値 -> 関係>はＫｎＯＳが完全逆転したデータ・モデルであることを意味する。ＫｎＯＳは、アトミック・データ・インスタンスを、連続的にカプセル化されたコンテキストに、型分類によって、および各データ・インスタンスのための（ＫｎＯＳが参照を記憶する）記憶機構の内部に、ベクトル・キー形式で、そのデータ・インスタンスに関連する全ての連想に対して記憶する。ＫｎＯＳ用語では、類似のコンテキストの特有のカプセル化されたデータ・インスタンス値は、「アイテム」と呼ばれる。アイテムは型（コンテキスト）により分類され、コンテキストでカプセル化される。コンテキストはリポジトリによりカプセル化され、リポジトリは環境によりカプセル化される。データ・インスタンスの間の全関係は、複雑ではあるが、２つのアイテムの間のバイナリ連想にカプセル化される。次に、連想は、ＶＫセットに編成し関連するアイテムの内部でカプセル化することによって、意味論的（または、他の概念的）コンテキストにより型分類される。簡単に言うと、環境のカプセル化されたメンバはリポジトリであり、リポジトリのカプセル化されたメンバはコンテキストであり、コンテキストのカプセル化されたメンバはアイテムであり、アイテムのカプセル化されたメンバは他のアイテムを有する連想の分類されたセットであり、他のアイテムはベクトル・キー（ＶＫ）として表され、意味論的（または、他の）コンテキストによりＶＫセットに分類される。この基本的な編成は、ＫｎＯＳが効果的にデータ値を関係に関連付けることを可能にする。
細分性：
また、如何にしてデータ・モデルが編成されるか（即ち、<関係 -> データ値>または<データ値 -> 関係>の何れであるか）も、データ・モデルの細分性を決定する。細分性は、データ・モデルが別々にアクセス可能な構成要素を含む範囲である。別々にアクセス可能な構成要素が多いほど、細分性が大きくなる。細分性が大きいほど、データ・モデルが更に柔軟になる。
データ・モデルの細分性は、独立に確立できない。データ・モデルの細分性は、主要な編成規則のサブジェクト（即ち、<サブジェクト -> オブジェクト>）に基づいて単独で決定される。もしモデルが規則<関係 -> データ値>により編成されるなら、データ・モデルの細分性は関係の最小要素（サブジェクト）である。リレーショナル・モデルに対して、関係の最小要素はリレーショナル・タップル（即ち、リレーションの１インスタンス、テーブルの１行）である。さもなければ、モデルは転置規則<データ値 -> 関係>により編成され、データ・モデルの細分性はデータ値の最小要素である。データ値は、リレーショナル・モデルの特有のゼロでない各セル値に類似する。この理由のために、リレーショナル・モデルに対して逆転したモデルは、ＫｎＯＳのように、セルラ細分性を有するものとして記述されるが、リレーショナル・モデルは、行レベル細分性を有する。
ＫｎＯＳは、リレーショナル・テーブルのセルラ値の特有の各インスタンスを（アイテムと呼ばれる）独立した概念として扱う。ＫｎＯＳアイテムはＫｎＯＳ設計の基礎なので、ＫｎＯＳはリレーショナル・データをセルラ・レベルで表現できることを意味する。ＫｎＯＳは、セルラ細分性を有するものとして適切に特徴付けられる。換言すれば、行によって情報を読み書きするリレーショナル・モデルとは異なり、ＫｎＯＳは特有のセルラ値によって所定の各コンテキストの内部で情報を読み書きする。
各ＫｎＯＳアイテムはその内部でカプセル化され、他の全ての関連する概念（アイテム）への特定の参照は、その特定の行の全セルラ値、その特定のセルラ値を有するテーブルの他の全てのセル、およびそれらの行の他の全ての関連する概念、等を含む。ＫｎＯＳにデータ値（または、データ値の記述）を提供するとき、ＫｎＯＳの編成規則がそれらのデータ値に関連する全関係を提供できるという点で、これは編成規則<データ値 -> 関係>を満足させる。要約すると、ＫｎＯＳはデータ・インスタンス中心であり、リレーショナル・モデルは関係中心である。
要約すると、リレーショナル・モデルの細分性は、タップル（テーブルの行）である。もしタップルをリレーショナル・モデルに明らかにすることが出来たら、リレーショナル・モデルはそのタップルに関連する（または、含まれる）全てのデータ値を戻すことが出来る。ＫｎＯＳの細分性は所定のコンテキストのための特有の各データ値であり、所定のコンテキストは各々が特有の区別可能な概念（または、アイテム）であり、アトミックである。もし単一の特有のデータ値（アイテム）をＫｎＯＳモデルに明らかにすることが出来たら、直接的に関連する全てのアイテムをそのアイテムに戻すことが出来る。
ＫｎＯＳをリレーショナル・モデルと比較することは便利である。本当に、任意のリレーショナル・モデルは、最初に完全に正規化することによりＫｎＯＳ表現へ完全に同化でき、全ての特有のデータ値をテーブルの内部でバイナリ連想として行×列オリエンテーションに基づいて分類する。しかし、転置は真ではない。リレーショナル・モデル・データベースは常にＫｎＯＳモデルで完全に表現できるが、ＫｎＯＳデータベースはリレーショナル・モデルにより常に表現できるとは限らない。また、ＫｎＯＳと比較されるとき、同じ記述が階層的なモデルおよびネットワーク・モデルにも当てはまる。ＫｎＯＳは、データ・モデルに基づく任意のレコード・セット（または、テーブル）よりも更に柔軟なデータ・モデル化パラダイムである。単純にリレーショナルに表現できないＫｎＯＳ企業モデルを構築することが可能である。
従って、リレーショナル・モデルに関連するＫｎＯＳを考慮することは便利であるが、この限定された方法で定義することはＫｎＯＳ発明に対して有害である。リレーショナル・モデルとは違って、ＫｎＯＳのアイテムは、ユーザにより区別できる任意レベルの抽象化で定義できる。例えば、任意のデータ・インスタンス（即ち、任意のデータ情報、または区別可能な知識）は、単一のＫｎＯＳアイテムである。それは特性、決定要素、キー、テーブル、列、行、クラス型、モデル、プログラム、関数、方法、オペレーション、表示要素、イメージ、クェリ、データ・モデル、ビュー、リポート、ユーザ・ディスプレイ・スクリーン、データ型、ファイル型、アイテム・パス、ファイル名、テーブル名、コンピュータ名、データベース、ＵＰＣコード、シリアル番号、部品番号、ＵＲＬ、ユーザ、プロトコル、接続、メッセージ、ステータス、品質、クラシファイア、ワード、センテンス、パラグラフ、ページ、チャプタ、ボリューム、オブジェクト、パーティション、セクタ、ＢＬＯＢ、ＣＬＯＢ、ポインタ、または参照でもよい。ＫｎＯＳアイテムは、ユーザが識別できる（区別可能な）任意の概念でよい。
要約すると、ＫｎＯＳは無制限のｎ次元モデル化環境であり、リレーショナル・モデルは折り畳まれた２次元表現である。もしリレーショナル表示だけが快適ならば、ＫｎＯＳはユーザに容易に対応できる。ＫｎＯＳデータ・モデルの細分性に関する決定は、実施者に残される。ＫｎＯＳは、如何にしてデータが編成されるべきかという次元についての先入観をもたない。好ましい実施例では、ＫｎＯＳは全面的に自己参照モデル化環境であり、インプリメンテーションに関連する全てがＫｎＯＳデータベースに適切な型のＫｎＯＳアイテムとして記憶されることを意味する。
対称性
この［本発明の詳細な記載］全体を通して、本文は対称性を参照し、ａ）相互類似性、ｂ）フォームおよび配置の類似性、およびｃ）サイズ、形状、および位置における対応を意味する。
本明細書は、なぜ対称性がモデル化プロセスに対する重要な特徴なのかを詳しく述べない。モデルが対称であるほど、定義、変更、処理が更に単純で効率的であることを言えば十分である。また、モデル対称性は、プロセッシングにおける並列化に対して重要である。モデルが対称であるほど、更に容易に、および更に完全に並列処理できる、
リレーショナル・モデルは、関係の定義を対称性の解析を通してシークする。いったん分かれば、関係は対称性によって完全に特徴付けられる。類似の対称性を有するように後で決定された候補となる別個の任意の関係は、同じ関係に組み合わされる。次に、残りの特有の非対称に定義された関係は、正規形でリレーショナル・モデルを構成する。従って、非対称な表現は、リレーショナル・モデルにおける定義の主要な手段として使用される。正規形で適切に構成されるとき、リレーショナル・モデルは１００％非対称である。他の事柄の中で、これは、データ・モデルが構成される前に全ての企業の関係が正しく理解されなければならないことを意味する。もしリレーショナル・モデルの２つの別個の構成要素が後で対称または構造的に合同（テーブルの同じ列に含まれることを意味する）であると決定されたら、データ・モデルは２つの構成要素を組み合わせるように修正されなければならない。
ＫｎＯＳモデルは関係に基づかず、むしろ特有のデータ値に基づく。ＫｎＯＳ関係は２つのデータ・インスタンスの間のバイナリ連想のセグメントで構成されるものとして定義され、アイテムとしてカプセル化され、多次元ベクトル・キーとして表現される。ＫｎＯＳは最初の完全に対称なコンピューティング・パラダイムとして特に設計され、対称な値、関係、および構造で構成される。ＫｎＯＳ対称性の議論は、値対称性から始める。
値対称性
ＡＳＣＩＩ値は全面的に非対称である。何故ならば、ＡＳＣＩＩ値はａ）相互類似性、ｂ）フォームおよび配置の類似性、およびｃ）サイズ、形状、および位置における対応を欠くからである。全データ値、概念、等（ＫｎＯＳアイテム）の大部分はＡＳＣＩＩ値によって表現され、主な例外はバイナリ・ラージ・オブジェクト（ＢＬＯＢ）である。データ値がＡＳＣＩＩ形式で表現されるとき、色々な理由から記憶および処理が困難である。その結果、殆どのデータ保管ＤＷＨアプリケーションは、対称性およびコンパクト性をコンピューティング・プロセスに注入しようとして、ビットマップ表示をＡＳＣＩＩ値の代わりに用いる。ＤＷＨはビットマップをローカライズされたベースで使用するが、ＫｎＯＳは完全な値対称性を全般的スケールで有する。
ＫｎＯＳは、全てのアイテムのＡＳＣＩＩ値表現（ここでは、データ・インスタンス、またはＴｈＯｈＴと呼ばれる）を全面的に対称な多次元参照（ここでは、ベクトル・キーと呼ばれる）に変換することにより、１００％値対称性をコンピューティング・パラダイムに注入する。別々の各アイテムは特有のベクトル・キーに割り当てられ、最初にＫｎＯＳコンピューティング環境に導入され、しかも、それ以降、ベクトル・キー割当は決して交替、変更されず、他の任意のコンテキストで再使用されない。ＫｎＯＳベクトル・キーは、各データ・インスタンスに対して全面的に対称なプロキシである。換言すれば、１つのＫｎＯＳベクトル・キーを他と比較するとき、アクティビティはａ）相互類似性、ｂ）フォームおよび配置の類似性、およびｃ）サイズ、形状、および位置における対応を有する。この対称性は、図２３「値対称性」に示される。
任意の動作（更新、またはクェリ）がＫｎＯＳで始まるときはいつも、最初のステップは常に、トランザクションでパラメータとして表される任意のデータ・インスタンスのベクトル・キーを決定することである。もしＫｎＯＳに呈示される任意のデータ・インスタンスが新しければ、ＫｎＯＳは（もしクェリなら）動作を拒否するか、または（もし更新なら）ａ）新しいデータ・インスタンスを特有のベクトル・キーに割り当て、およびｂ）新しいデータ・インスタンスをＡＳＣＩＩ辞書に追加するかの何れかである。次に、データ・インスタンスに対するＫｎＯＳベクトル・キーは、コンピューティング・オペレーションのためのＫｎＯＳにより排他的に使用される。事実上、ＫｎＯＳは非対称なデータ値を入り口で変形し、それ以降、完全に対称なベクトル・キーと一緒にプロキシとしてのみ機能する。
ＫｎＯＳの対称な参照は、モデルの各次元に特有のバイナリ整数の順序付きセットから成るベクトル・キーという形をとる。本発明の一般的な実施例では、ベクトル・キーは、環境、リポジトリ、コンテキスト、およびアイテムとして知られる４つの次元を有する。ＫｎＯＳベクトル・キー（ここでは {E,R,C,I} と呼ばれることが多い）は３２ビット（１ワード、４バイト）の４つの別個のバイナリ整数から各々が成り、各バイナリ整数はその次元に特有である。所定のアプリケーションに対する参照次元の実際の数は、４より少ないか、または多い。４つの次元は、単純な好ましいインプリメンテーションである。複数の実施例では、３２ビットワードの３０ビットだけがベクトル・キーとして使用され、２ビットは参照型識別されたシステムをマークするために残されるが、全ビット幅が必要とする実施例のために利用可能である。ワード幅はコンピューティング環境により定義され、従って、もし６４ビットワード幅が利用可能なら、参照もそうであり得る。
ベクトル・キーは、アイテム参照に限定されない。また、ベクトル・キーは、コンテナ・ヘッダに同じ {E,R,C,I} 形式（環境ヘッダ = {E,0,0,0}, リポジトリ・ヘッダ = {E,R,0,0} 、およびコンテキスト・ヘッダ = {E,R,C,0}）で適用でき、（{C,R,N,O} 形式で）リポジトリ・ディレクトリ、および（{I,R,N,O} 形式で）コンテキスト・ディレクトリの両方に適用できる。ＶＫセット（ベクトル・キーの配列）は型により一定でなければならず、 {E,R,C,I} 形式のベクトル・キーは {I,R,N,O} 形式のベクトル・キーと混合できない。
関係対称性
リレーショナル・モデルでは、関係は２つの方法（基本的なリレーション、または共有識別子値 （ＦＫ））の１つで記録される。これら２つのアプローチは完全に異なり、対称性を全面的に欠く。定義により、２つのリレーション（または、共有識別子値）は類似していない。もし２つのリレーション、または２つの共有識別子が類似していたら、それらは組み合わされて１つになる。関係を記録するためのリレーショナル・モデルの方法は、実際には識別力においてそれ自体を誇り、識別力は対称性を欠くと言われる。
ＫｎＯＳの基本的な編成規則（<データ値 -> 関係 >）はリレーショナル・モデルに関して逆なので、ＫｎＯＳは全関係が２つの（および、２つだけの）データ・インスタンスを比較することを要求する。ＫｎＯＳは、れらのバイナリ関係を連想と呼ぶ。また、任意のデータ値から付随的な関係へ行く組織的要求は、全バイナリ連想が本来的に双方向（転置）であることを意味する。図２４「関係対称性」の実施例は、 shows that ２つのデータ・インスタンス（アイテム = 「White Beans」、およびアイテム = 「$13.45」）が互いに関連することを示す。特定の 意味論的コンテキストは、ａ）「White Beans」 have-price-of 「$13.45」、およびｂ）「$13.45」 is-price-of 「White Beans」である。何れの意味論的コンテキストも、基本的な編成規則（<データ値 -> 関係 >）で与えられたＫｎＯＳにアクセス可能でなければならない。
連想の内部でビューされようと間でビューされようと、ＫｎＯＳのバイナリ（双方向関連）は１００％対称である。ＫｎＯＳが双方向関連を２つのアイテムの間に登録するとき、関連はａ）相互類似性、ｂ）フォームおよび配置の類似性、およびｃ）サイズ、形状、および位置における対応を有する。
図２４に示される実施例の意味論的コンテキストの短い評価を行う点に価値がある。リレーショナル・モデルもＫｎＯＳも、正確な２つの意味論的コンテキストを、それほど多くのワードでは記録しない（即ち、 have-price-of および is-price-of）。各モデルは、「Price」が何とかして関係に含まれることだけを記録する。リレーショナル・モデルは、「Price」を列の名前（属性）として記録し、ＫｎＯＳは「Price」をコンテキストの名前として記録する。（図２４の左上に示される）意味論的バイナリ・データ・モデルは、各関係の意味論的コンテキスト全体を直接的に記録する。ＫｎＯＳは関係の意味論的コンテキストを型の類似性によってマップし、従って意味論的コンテキストは、それらの次元のコンテキストの内部で連想を読むこと、およびコンテキストをカプセル化することによって直接的に推論できる。
構造的対称性
データ・モデルにおける対称性の最後の最も重要な次元は、構造的対称性である。構造的対称性は、如何にしてモデルの部分が記憶されるかに言及する。リレーショナル・モデルの編成規則<関係 -> データ値>は、データが関係によって記憶されることを意味する。関係をリレーショナル・モデルで図示することの意味は非対称なので、データ記憶の構造は非対称である。ＫｎＯＳの編成規則はデータ値（<データ値 -> 関係 >）によって駆動されるので、ＫｎＯＳは構造的対称性を有することが出来る。
実際には、図２５「構造的対称性−ＫｎＯＳアイテム」および図２６「構造的対称性−ＫｎＯＳコンテキスト」に示されるように、ＫｎＯＳ記憶構造における抽象化の異なる各レベルは対称である。ＶＫセットのように、アイテム・コンテナの内部でカプセル化された関係は、構造的対称性を有する。各アイテムは、他の全てのアイテムと構造的に同じである。アイテムは型で分類され、コンテキストに記憶される。アイテムの各コンテキストは、アイテムの他の全てのコンテキストと構造的に同じである。実際には、ＫｎＯＳコンテナの異なる型が異なる機能を果たすが、ＫｎＯＳコンテナはコンテナ型全体にわたって構造的に対称である。アイテム・コンテナ、およびコンテキストと呼ばれるＫｎＯＳコンテナは、構造的に対称である。同じ構造的対称性はリポジトリ・コンテナと一緒に存在し、環境コンテナも同様である。
図２７「ＫｎＯＳ対称性」は、ＫｎＯＳモデルをどんなに見ても、ＫｎＯＳモデルは完全に対称であることを示す。値、関係、または構造を考慮してもしなくても、これは真である。
ＫｎＯＳモデルの構造的対称性の内部では、コンテインメントの対称性も存在する。他の全てのＤＢＭＳでは、データ値はそれらのコンテナを参照しない。何故ならば、それらが単にスペースを占有し、位置をコンテナの中に有するからである。いったんコンテナから読み出したら（即ち、テーブル、または木）、データ値はそのコンテナを参照せず、従ってコンテキストは外部から維持されなければならない。データ・インスタンス読み取りの数が増えるほど、これは困難になる。ＫｎＯＳのアイテムとしての全データ・インスタンスは、アイテムがベクトル・キーを介する本来的な自己参照である点において、それらのコンテナ（コンテキスト）と対称な関係を有し、従って、それらのコンテナ（コンテキスト）の定義参照により、それら自体を呈示する。コンテキストは、アイテムをそれらの「内部で」常に参照する。加えて、実際のロケーションへのアイテムの論理的−物理的マッピングは、ＫｎＯＳが実際のロケーションからアイテムが存在するところへの物理的−論理的マッピングを維持する点において対称である。
ベクトル・キー:
ベクトル・キーは、２つの別個の目的を有する。第１は、各々および全てのアイテムを識別する特有の識別子として作用することである。第２は、ＫｎＯＳがアイテムを発見することを可能にするロケータ・キー（または、論理インデックス）として作用することである。ベクトル・キーを任意のアイテムへの全般的参照として使用することは、ＫｎＯＳが連続的にカプセル化されたコンテナ参照を{E<R<C<I}において（好ましい実施例では、キーの要素として）符号化し、それらの要素を連続的にカプセル化された各コンテナへの直接インデックスとして使用することを可能にする。ベクトル・キーは識別子、および各アイテムに対するロケータとして作用するので、アイテムにおいてカプセル化された関連の任意の次元の任意のＶＫセットにおいて関連を指定するために直接的に使用される。
本明細書全体を通して使用される用語「次元」は、２つの別個の事柄ａ）アイテムの参照の次元、およびｂ）アイテムの関係の次元を意味する。ベクトル・キーは、本質的に、アイテムの参照の次元の内部で一意に配置される位置への論理インデックスである。また、ベクトル・キーはアイテムを一意に識別するので、アイテムの間の関係を記録するためにも使用される。従って、１つの次元（または、他のアイテムの参照のＶＫセット）に分類されるとき、ベクトル・キーは関連するアイテムを一意に識別し直接的に配置するために使用される。ＫｎＯＳ連想の分類は、関係次元を構成する。
ＫｎＯＳは、次元を折り畳まれた（または、連続的にカプセル化された）と言われる。その親（または、エンベロープ）コンテナの内部で各々が一意に番号を付けられるように、アイテムは一連の明快に境界を付けられたコンテナの内部に収容される。アイテム・コンテナは、親コンテキストの内部で論理的に配置できる。アイテムのコンテキストはそのリポジトリ・コンテナの内部で論理的に配置でき、アイテムのリポジトリはその環境コンテナの内部で論理的に配置できる。ベクトル・キーだけを用いて、特定のアイテムが配置されるまで次元から次元へ通過することが可能である。各アイテム・コンテナは、その関係次元をカプセル化する。
本発明の好ましい実施例では、バイナリ連想または関係も４つの次元（「parent」「child」「link」または「related」）に分類され、各アイテム・コンテナの内部でカプセル化される。ここで、各次元の関連のバイナリ状態は、関連するアイテムを参照するベクトル・キーの有無により各々表現される。ベクトル・キーの存在は、関連する各アイテムをその次元で一意に識別し、ＫｎＯＳに各アイテムを直接的に配置するための手段を提供する。従って、関係次元は、アイテム次元の内部で折り畳まれる。
各環境は、常に自らの第１の参照である。全ての折り畳まれたアイテム次元が露出されたら、いったん所定の環境が入力される。図２２「コンピューティング環境の間の相互参照」を参照のこと。一般的な実施例では、各環境は３つの主要な折り畳まれたアイテム次元（R, C, および I）、および１つの主要な 外部次元（Ｅ）を有する。ここで、一般に E = 1 はその環境への自己参照である。（一般に、 E=0 は「Creator」または「License Master」を参照し、）他の環境は遭遇したものとして追加される。この方法で、全ての環境は、異なる他の環境への「Ｅ」参照を有する。
「Ｅ」は論理的参照であり、従って、環境値（例えば、「２」）は、多分、異なるＫｎＯＳ環境の異なる事柄を参照することを銘記するのは重要である。換言すれば、「Ｅ」が何れかである特定の割り当てを有するマスタ環境リストは存在せず、リストは何らかの権限により維持されなければならない。これは、一般に参照可能な「Ｅ」の定義されたセットの割当を排除しない。例えば、 E=0 はＫｎＯＳに対する中央ライセンス権限である。 E=411 は、ＫｎＯＳシステムに対するマスタ知識ベースである。 E=611 は保守、または技術サポート、等に対するものである。実際には、ＫｎＯＳは最初の「ｎ」「Ｅ」をこれらの型のアプリケーションに対して予約する。
折り畳まれた４つの次元 （{E,R,C,I}）に特有のカプセル化されたベクトル・キーを有する各アイテムを用いて、全ての環境の全てのアイテムは、各アイテム自体のベクトル・キーを有する全ての関連するアイテムを分類しカプセル化することにより、全ての環境の他の全てのアイテムに関連することが出来る。各環境の多次元参照スキームは、内部で完全に首尾一貫している（即ち、その環境の内部の何れの他のアイテムが参照として使用しても、環境の内部の任意のアイテムに対するベクトル・キーは特有である。
特定のメモリ・アドレス（または、特定の物理的ロケーション・ポインタ）ではないことを理解することは重要である。各アイテムは他の全ての適用可能なアイテムに関連するコンテキストに配置されるが、配置は参照により行われ、参照はコンテキストの内部でカプセル化され、物理的に隣接する必要はない。アイテムは、論理的参照によって（アドレス、または物理的ロケーションによってではない）常に記憶されて検索される。従って、ＫｎＯＳの必要条件を提供し最適に効率的である限り、何れの潜在的機構が実際にアイテムを記憶媒体に記憶するために使用されるかは必ずしも重要ではない。アイテムの記憶装置および検索に対する一般的な潜在的機構が、ここで記載される。好ましい記憶機構がＫｎＯＳの論理的レイヤおよび物理的レイヤの間の対称性を有し、論理的ロケーション・システムが物理的ロケータ・トークンをカプセル化し、物理的記憶システムが論理的 ロケータ・トークンをカプセル化することを銘記する。
任意のアイテムに関連するＫｎＯＳデータ・インスタンスは、所定のコンテキストのリレーショナル属性 （例えば、 Person = 「Duane Nystrom」, Qty = 「３」, Stock = 「White Beans」, または Price = 「$13.45」）の単一インスタンスと類似する。コンテキストはリレーショナル属性（例えば、 Person, Qty, Stock, Price）全体に類似し、値の全範囲を含む。換言すれば、ＫｎＯＳコンテキストは、アイテムの所定の型の全てのアイテムを保持できる。ベクトル・キーのリポジトリ次元は、コンテキストの集合である。それは、実世界ロケーション、特定のマシンの複雑さ、またはデータ（例えば、領域、地域、または市（例えば、 New York, NY または Los Angeles, CA リポジトリ））の他のユーザ／アプリケーションに依存する編成を参照する。ベクトル・キーの環境次元はリポジトリの集合であり、リポジトリは、世界ビュー（例えば、国家または大陸（例えば、アメリカ合衆国、またはカナダ環境））を表示するために使用できる。さらに詳細には、それは、リポジトリの収集を収容または仲介する実際の実世界コンピューティング環境を識別するために一般に使用される。実際のアプリケーションでは、特にこれらの次元はＫｎＯＳのアイテム次元だけを参照するので、４つの次元を有する参照は、任意のデータ管理問題を扱うのに十分である。関係モデル化の意味論的コンテキストは、ＫｎＯＳの無制限の次元を（以下に記載される）連想の分類およびセグメント化を通して有する。
図１２「多次元参照モデル」は、多次元参照スキームの一般的なインスタンスを示す。ベクトル・キー記号 （{E,R,C,I}） が示すように、ベクトル・キーは、単純に連結された４つの別個の１ワードのバイナリ数字（ 例えば、 {1,38,1,5} （環境 #1, リポジトリ #38, コンテキスト #1 および アイテム #5））である。３２ビット・マシン（１ワードに対して４バイト）では、ベクトル・キーの４つの要素の各々が、一般に３０ビット・バイナリ整数（即ち、230 = 0 から 1,073,741,824 （ベース10））に拘束される（しかし、全３２ビットが使用できる）。従って、全ベクトル・キーは、 230 × 230 × 230 × 230 = 2120 個の異なるアイテムを参照または識別できる。
多次元参照モデルは、広く拡張可能である。単一ロケーションで始め、第２、第３を等を追加することが可能である。後で、ロケーションは複数の環境に分割される。単一ロケーションに対して、 {0,1,1,5} が有効なベクトル・キーであり、唯一のリポジトリのコンテキスト #1 の第５のアイテムを参照する。後で、もし第２のリポジトリが追加されたら、それはリポジトリ #2 になる。第１のリポジトリのデータに対して、何も変える必要はない。１つの環境／リポジトリからのデータは、アプリケーションによって、他の任意の環境（または、リポジトリ）から混乱なしに読める。
ＫｎＯＳアイテム：
ＫｎＯＳアイテムは、アプリケーションとは独立した基本的なデータ構造に基づく。図１３「ＫｎＯＳアイテムの構造」は、アイテムの概念的および完全に形成された物理的表現の両方を示す。物理的表現は、右側に示される。アイテムは、可変数のワード（３２ビット・マシンでは、各ワード = ３２ビットまたは４バイト）から成り、ここでは４ワード／行で示される。
右側に示される行×列テーブル表現は厳密に説明目的であり、アイテムの実際のインプリメンテーションを表現しない。１８行×４列構造は、実際には存在しない。図１３に示される「Duane Lewellyn Nystrom, Esq.」アイテムは１８×４＝７２ワードをもたないが、むしろ７１ワードをもつ。行６の灰色セルは存在しない。実際には、アイテムは可変長レコードである。図１３に示されるアイテムの行×列表現は、アイテム自体のベクトル・キー（および、関連するアイテムのベクトル・キー）を読むことを容易にすることを意図する。アイテム自体のベクトル・キー（または、アイテムのＶＫセット）に関しては、ワードの４列がベクトル・キー {E,R,C,I} の次元を表す。さもなければ、４列はアイテムに対する意味をもたない。
アイテムの４ワードの第１の「行」は、図１３のアイテムに対する主要な自己参照ベクトル・キー {1,38,1,5} である。１２ワードから成る第２，第３，および第４の「行」がアイテムの 「マップ」を与え、如何にして可変長アイテムの残りを読むかを記述する。図１３のアイテム・マップは、「|Duan|e Le|well|yn N|ystr|om, |Esq.|」と示されるように、アイテムの データ・インスタンスが次の７ワードであることを述べる。
また、各アイテムが所定のアイテム（データ・インスタンス、データ値、概念）に対して定義された全ての連想の和を完全にカプセル化するように、各アイテムは、（ベクトル・キー・セットと呼ばれる）分類された（次元付きの）セットに配列された関連するアイテムの無制限の数のベクトル・キーを連鎖してカプセル化する。単一のアイテムの内部の異なるＶＫセットは、異なる型（または、分類）の連想に対応し、一般に４つの主要な型がある。図１３のアイテム・マップは、第１に３つの（各々が４ワードの）「parent」ベクトル・キーのＶＫセットがあり、次に２つの「child」ベクトル・キーのＶＫセットがあり、次に２つの「link」ベクトル・キーのＶＫセットがあり、２つの「related」ベクトル・キーのＶＫセットが続くことを示す。「parent」「child」「link」および「related」がＫｎＯＳにより使用される関係（意味論的コンテキスト）の４つの一般的な分類（または、次元）であり、「is」「has」「does」および「goes with」の意味論的コンテキストを表しているよう見える。任意の数の他の意味論的コンテキストがいつでも追加でき、ＫｎＯＳによって無制限に課される。
もし所望するなら、追加的な関係する要素がアイテムに埋め込まれる。これらは、アイテム埋込要素（または、「ＩＥＥ」）と呼ばれる。ＩＥＥＥはデータ（例えば、部品番号、 住所、またはＶＫセット）であり、他のアイテムを参照する。図１３は、「Duane Lewellyn Nystrom, Esq.」アイテムが埋め込まれた電話番号（「514-824-9949」）および住所 （「3307 Blake Lane, Unit 47」）を有することを示す。また、埋込要素は別々のアイテムとしても表され、主要なＶＫセット次元の１つを通して、または単一ベクトル・キーまたはＶＫセットの何れかとして埋込要素に生成された第２の次元を通して明白に参照される。
埋込アイテム・データは任意である。もし人間についてのリポジトリに入力される殆どのクェリも人間の電話番号を要求し、どの独立したクェリも電話番号により行われないなら（即ち、誰が電話番号「514-824-9949」を有するのか？）、これらの値を各人間アイテムに埋め込むことも納得できる。さもなければ、「電話番号」は右側にあるコンテキストである。例えば、もしリポジトリがクェリを電話番号によってサポートしなければならないとしたら、電話番号を埋め込むことは、全アイテムに含まれる（全埋込アイテムもＡＳＣＩＩ辞書に追加されるまで（次節を参照）、相互参照され、従って、２分木検索によって識別可能かつアクセス可能な）データを通した完全なサーチ無しでは機能しない。
ＫｎＯＳのコンテナの各型はアプリケーションとは独立した基本的なデータ構造であり、その中では構造的に合同で、自己参照し、およびコンテンツをカプセル化し、ＫｎＯＳを使用して構築された任意のアプリケーションから完全に独立している。最低レベルから最高レベルまでリストにしたＫｎＯＳコンテナに対して仮定した分類スキームは、アイテム、コンテキスト、リポジトリ、環境である。コンテキストはいくつかのアイテムを収容し、リポジトリはいくつかのコンテキストを収容し、環境はいくつかのリポジトリを収容する。用語「コンテキスト」は特定の型のコンテナを参照し、即ち、コンテナはコンテキスト的定義または分類（即ち、人、顧客、製品、会社、種、色、部品番号 ...）によりグループ化された全アイテムを論理的に収容することを銘記する。
ＫｎＯＳコンテキストおよびリポジトリ：
図１８の左半分「コンテキストおよびアイテム構造」は、アイテムのコンテキストを示す。図１８の右側は、その様に含まれたアイテムの１つを示す。構造的に、アイテムおよびコンテキストの間に違いはない。アイテムはメンバを有し、メンバはベクトル・キーのＶＫセットである。コンテキストは追加メンバを有し、追加メンバはアイテムである。
コンテキストでは、たとえ同じ構造および同じ数のワード要素をもっていても、アイテム・メンバのベクトル・キーはリテラル {E,R,C,I} ではない。定義によると、所定の数のコンテキストは、他の全てのメンバの同じコンテキスト、およびコンテキスト自体でさえ有するのと同一の「Ｅ」「Ｒ」および「Ｃ」値を有する。従って、アイテム（Ｉ）値だけ（または、ベクトル・キーの４つの要素の一番右）が、コンテキストのアイテム・メンバのベクトル・キーで維持されるのに必要である。他の３次元（即ち、「Ｅ」「Ｒ」および「Ｃ」）への供給は、「物理的ロケータ」インデックス、バイト中のアイテム・サイズ、ステータス、および状態フラグに対して使用される。全メンバのベクトル・キーは記憶された順番でアイテム（Ｉ）値により維持でき、アイテム（Ｉ）値はコンテキストの任意の指定されたアイテムの迅速なルックアップを可能にする。
また、コンテキストのこのメンバ情報の使用も、図１６「 {0,6,8,2} を物理的媒体に配置」に示される。図１６のアイテム #3 は、コンテキストを示す。アイテム #4 および #5 は、コンテキストのメンバ（２ペアに４ワード）を示す。通常の {E,R,C,I} では、「Ｉ」は４番目の位置にある。「Ｅ」「Ｒ」および「Ｃ」はコンテキストの中に維持される必要がないので、コンテキストのメンバ・ベクトル・キーは、一番左の位置にある「Ｉ」から始まる。これらの {E,R,C,I} は {I,R,N,O} としてより良く記述され、アイテム、相対、次、およびオフセットを意味する。左から右へ読むと、コンテキストのメンバ・エントリはアイテムの実際の数を与え、（最後の２つの位置Ｎ，Ｏを参照する）アイテム・ロケータ・ディレクトリの相対位置が続き、ディスク上で遭遇する次のアイテムの数が続き、アイテムのデータ・インスタンスへのページ・オフセットが続く。
類似の状況が、リポジトリ・コンテナと一緒に存在する。リポジトリの場合、メンバがコンテキストを記述し、コンテキストはベクトル・キーが {C,R,N,O} としてより良く記述されることを意味し、コンテキスト、相対、次、およびオフセットを意味する。左から右へ読むと、リポジトリのメンバ・エントリはコンテキストの実際の数を与え、（最後の２つの位置Ｎ，Ｏを参照する）コンテキスト・ロケータ・ディレクトリの相対位置が続き、ディスク上で遭遇する次のコンテキストの数が続き、コンテキストのデータ・インスタンスへのページ・オフセットが続く。図１７「リポジトリ構造」が、これを図示する。
図１６は、 {E,R,C,I} = {0,6,8,2} であるアイテムに対して、アイテム #2 へのコンテキスト・メンバ ベクトル・キーは {I,R,N,O} = {2,3,6,7} であり、コンテキスト #8 へのリポジトリ・メンバ・ベクトル・キーは {C,R,N,O} = {8,3,1,5} であることを示す。 {E,R,C,I}, {I,R,N,O} または {C,R,N,O} の何れでも、全てがベクトル・キーであり、グループ化されるか分類されるときは、ＶＫセットとして参照される。
これは、ＫｎＯＳのコア・パワーを図示し、アイテムは、ディスク媒体に埋め込まれたアイテムのベクトル・キー、および論理的−物理的ディレクトリだけを用いて配置できる。 {C,R,N,O} 形式のＶＫセットは、ディスク・リポジトリ・ディレクトリである。 {I,R,N,O} 形式のＶＫセットは、ディスク・コンテキスト・ディレクトリである。ＫｎＯＳは、任意のアイテムを、その {E,R,C,I} を最初にそのコンテキストの {C,R,N,O} と、次にそのリポジトリの {I,R,N,O} と比較することにより配置および検索できる。
アイテムに対する配置およびフェッチ・プロセスの第１のステップは、正しい環境を配置することである。環境から、 {C,R,N,O} 形式のリポジトリ・ディレクトリはアクセス可能である。
リポジトリ・ディレクトリを使用して、ＫｎＯＳはトランザクション（この場合には {0,6,8,2}）により参照される {E,R,C,I} を {C,R,N,O} と比較する。{C,R,N,O} = {8,3,1,5} は、 {0,6,8,2} と一致する（即ち、 {E,R,C,I} の「Ｃ」が {C,R,N,O} の「Ｃ」値と一致する）リポジトリ・メンバ・エントリである。この場合、リポジトリ・ディレクトリ・エントリの「５」の「Ｏ」値は、親コンテキストを含むディスク媒体上のページに対するオフセットを与える。
コンテキスト・ディレクトリを使用して、ＫｎＯＳはトランザクション（この場合には {0,6,8,2}）により参照される {E,R,C,I} を {I,R,N,O} と比較する。 {I,R,N,O} = {2,3,6,7} は、 {0,6,8,2} と一致する（即ち、 {E,R,C,I} の「Ｉ」が {I,R,N,O} の「Ｉ」値と一致する）コンテキスト・メンバ・エントリである。この場合、コンテキスト・ディレクトリ・エントリの「７」の「Ｏ」は、親アイテムを含むディスク媒体上のページに対するオフセットを与える。
図１７および図１８は、論理的−物理的「ディレクトリ」の上記要素を物理的−論理的「ディレクトリ」からセグメント化する他のアクセス方法を図示する。ディスク・ロケーションのための物理的−論理的「ディレクトリ」は、各リポジトリ・コンテナのＶＫセットに配置され、ＲＡＭロケーションのために、ＫｎＯＳ自体の環境コンテナに配置される。ＲＡＭおよびディスク・ロケータの両方のためのページＩＤオフセット参照は統合され、別々のオペレーティング・システム・メモリおよびディスク管理サブシステムに対する必要性を除去する。ページＩＤによる全メモリ配置および配置解除は、ＫｎＯＳにより管理される。物理的レイヤ読み出し／書き込みだけがハードウェア・ドライバにより操作され、ハードウェア・ドライバはページＩＤオフセットに割り込み、それらをＲＡＭおよびディスク・システムの潜在的な物理的構造にマップする。
コンテキスト名およびアイテム・データ・インスタンス：
全ＫｎＯＳコンテキストは、コンテキストのアイテムのコンテンツを記述し分類する名前を有する。同様に、コンテキストの各アイテムは特有の データ・インスタンスを所定のコンテキストの内部で表現し、所定のコンテキストは、如何にしてユーザが各アイテムをコンテキストの内部で識別するかという意味で名前として可視化される。それらは識別のために使用されるので、コンテキストの中で各アイテムにより表現されるコンテキストの名前およびデータ・インスタンス値は、特有であるべきである。多くのコンテキストおよびカプセル化されたアイテムはユーザによって一意に命名できるが、出来ないものもある。
名前付きと名前無し命名されないＫｎＯＳ概念を説明する一番簡単な方法は、それをリレーショナル・モデルと比較することである。データ（３ＮＦ）の正規化されたテーブルがＫｎＯＳによって同化されるとき、テーブルの各列がＫｎＯＳコンテキストにマップされる。次に、ＫｎＯＳが１つのカプセル化されたアイテムが各コンテキストの内部で創出され、各コンテキストの名前 = 各々特有の、列のゼロでないセル値であり、ＫｎＯＳのデータ・インスタンスに対応する。これは、ＫｎＯＳアイテムとして、テーブルの各列で見出される特有の各データ値を同化する。もし「color」がテーブルの列にあれば、「color」はＫｎＯＳコンテキスト（属性、または列）の名前であり、種々の color 自体（ pink, green, lavender ）が「color」コンテキストの内部で参照されるアイテムである（即ち、「green」は、「color」コンテキストの特定のアイテムのデータ・インスタンスである）。もし「age」がコンテキスト（属性、または列）ならば、 age （1, 2, 3 ... n）に帰する基数は age のデータ・インスタンスである（即ち、「１４」は age データ・インスタンスである）。列の特有の各データ・インスタンス（即ち、個々のＡＳＣＩＩ値）は「データ・インスタンス」であり、各データ・インスタンスはベクトル・キー参照を有するアイテムに関連する。図１３「ＫｎＯＳアイテムの構造」の実施例では、データ・インスタンス = 「Duane Lewellyn Nystrom, Esq.」である。
もし色「brown」が３ＮＦテーブルの２つの異なる列で遭遇したら、２つの異なるデータ・インスタンスおよび２つの異なるアイテムが創出されたと考えられる（各列に１つの「brown」アイテム）。（２つの異なる名前を有すると思われる）２つの列は、例えば、「hair color」および「eye color」であり、「hair color」および「eye color」は関係の２つの異なる意味論的コンテキストである。「brown」は、２つの非常に異なる独立したコンテキストで、個人の髪の毛の色、および個人の目の色として独立に個人に関連することを銘記する。ＫｎＯＳは、これを別々のコンテキストとして同様に実施し、１つは「Hair Color」および１つは「Eye Color」として命名され、「brown」は各々におけるアイテムのデータ・インスタンスである。
従って、創出されたコンテキストは、列のようなコンテキストであると考えられる。行連想をＫｎＯＳに記録するために、行を表現するためのＫｎＯＳコンテキストも必要である。もしユーザが行の値を３ＮＦテーブルで命名できたら、一般にテーブルはテーブルのＰＫとして１属性（列）を有する主リレーションである。その様な場合、テーブルのＰＫを表現する１つのＫｎＯＳコンテキストは、テーブルに対する行プロキシである。
もしリレーショナル・モデルの主要なテーブルがＰＫとして機能する単一の列を有するなら、それは命名されたテーブルである。ＰＫ列の値は、テーブルの各行（または、リレーションのタップル）を一意に識別する。主要なテーブルがＫｎＯＳにより同化されるとき、テーブルのＰＫ列はＫｎＯＳの行プロキシ・コンテキストになる。図２「主リレーションの同化」に示されるように、「Stock」主リレーションは、２つの列「Stock」および「Price」を有する。これらは、ＫｎＯＳの内部に、「Stock」および「Price」と命名された２つのコンテキストとして同化される。「Stock」はテーブルのＰＫ（または、行の特有の識別子）なので、ＫｎＯＳの「Stock」コンテキストは、自動的に行のようなコンテキストである。構造においては他の任意のＫｎＯＳコンテナとは異ならないが、そのアイテムは同化されるテーブルの行（Stock テーブルの各行に対する１つのＫｎＯＳアイテム）を表現する。
対照的に、「Price」コンテキストは、 Price 列の特有の各ゼロでないセル値に対する１つのアイテムを有する。もし「$9.99」がテーブルの Price 列に２５２回現れたら、ＫｎＯＳは「$9.99」の１つの「Price」アイテムだけを有する。
これは、命名された場合（特有のＰＫとして働く単一の列を有する主リレーション）を図示する。もしテーブルが異なる種類の主リレーション（例えば、「人間」テーブル）であり、人間の名前が特有でなければ、他の単一列をＰＫ（例えば、社会保障番号、または従業員番号）として有する必要がある。
２または３以上の列が３ＮＦテーブルのＰＫとして必要とされるときはいつも、テーブルはリレーショナル・モデルの連想リレーションと呼ばれ、２または３以上のテーブルと関連することを意味し、各々は３ＮＦの中にある。これらはＦＫリレーションである。図３「連想リレーションの同化」は、タップルがユーザにより命名できない連想リレーションを示す。この Stock-Order テーブルは、２つの主リレーション（ Stock および Order ）を関連付ける。 Stock-Order テーブルのＰＫは Stock + Order である。特に、もし数千の「Stock」アイテムおよび数千の「Order」アイテムが存在したら、任意のユーザが、リレーションの各タップルに対するこの組合せを知っていそうもない。「Stock」および 「Order」の間の連想の組合せ（連想リレーションのタップル）は、大き過ぎて各行に対する名前を記憶できない。
例えば、誰も「Stock」アイテム「Pinto Beans」が「Order」アイテム「1111」に関連するのを知ることを期待しない。その様な場合、ユーザは「Order」アイテム「1111」に関連する全「Stock」アイテムの表示を求め、所望する「Stock」アイテムを表示から選択する。または、逆に、ユーザは「Stock」アイテム「Pinto Beans」に関連する全「Order」アイテムの表示を求め、所望する「Order」アイテムを表示から選択する。
もし単一の名前列が３ＮＦテーブルに存在しなければ、連想リレーションのように、テーブルのプロキシに対する別々のＫｎＯＳコンテキストがＫｎＯＳで例示されなければならない。この特別な行のようなコンテキストの名前は、おそらくリレーショナル・テーブルの名前である。これは、図３「連想リレーションの同化」に図示される。「Stock-Order」リレーションの「Stock」「Order」および「Qty」列は（上記主リレーションのように）列のようなコンテキストに同化され、 Stock-Order テーブルは（名前プロキシとして）「Stock-Order」コンテキストに同化される。この行のようなコンテキストのＫｎＯＳアイテムは実際の名前をもたず、人工的な名前（1*, 2*, 3*, ...n*）だけをもつことを銘記する。これが、命名されないリレーションと呼ばれる理由である。
いったん行のようなＫｎＯＳコンテキストの同化が識別されたら、バイナリ関連が各行の各列値の参照に対して確立する。これは、図５「ＫｎＯＳコンテキストへの関係の同化」に図示される。２つの行のようなコンテナが存在し、１つは Stock-Order 連想リレーションのため、１つは Stock 主リレーションのためのものであり、それぞれコンテキスト「３」および 「１」である。
リレーショナル・モデルの主リレーションに埋め込まれた行関係は、「Stock」および「Price」コンテキストに、アイテム間のバイナリ連想として、各非キー属性列へ、各行の「Price」およびＰＫ ＫｎＯＳコンテキストの各列のアイテム（この場合には、「Stock」）の場合に記録される。図５に示されるように、これは、各列の各データ値に対して創出されたアイテムに対するベクトル・キーだけを使用して達成される。同じことが、連想リレーション Stock-Order の行に対しても行われる。
要約すると、もしリレーショナル・モデルのタップルが特有の名前（ＩＤ）を有する１つの列をもつなら、それは主要な（または、命名された）リレーションと考えられる。ＫｎＯＳに同化されるとき、命名されたリレーションはテーブルの各列に対する１つのＫｎＯＳコンテキストに変わる。タップル名を含む単一の列は、テーブルに対する行プロキシとして扱われるＫｎＯＳコンテキストにマップする。もしリレーショナル・モデルのタップルが複数の属性（または、列）をＰＫにもつとき、連想または命名されないリレーションと考えられる。命名されないリレーションに対して、ＫｎＯＳはリレーションに対するプロキシとして機能する人工的なコンテキストを創出する。リレーションの全ての列の全てのデータ値は、行毎に、各列コンテキストからこの人工的な（プロキシ）名前コンテキストに関連する。
関係（意味論的コンテキスト）の次元：
連想分類は、ＫｎＯＳに対する基本的な概念である。ＫｎＯＳの一般的な実施例では、アイテムの間の全ての連想は４つの自然なカテゴリに分類され、４つの自然なカテゴリはアイテム参照に対する４つのデフォルトのＶＫセットに対応する。４つの連想分類は、図１３に「parent」「child」「link」および「related」として示される。自然な関連型の以下の説明は、実施例アイテムとして「cat」を使用する。
Parent: アイテムＢはアイテムＡの「parent」または「分類」であるという意味で、アイテム「Ａ」はアイテム「Ｂ」に属する。「child」は「parent」に属するという意味で、サブジェクト・アイテムはターゲット・アイテムまたは分類に属する。もしサブジェクト・アイテムが「cat」なら、ターゲット・アイテムは、例えば、「animal」「feline」または「pet」である。
Child: アイテムＡはターゲット・アイテムＢを所有、生成、もしくは分類するという意味で、または「parent」が「child」もしくは「children」を有するという意味で、アイテム「Ａ」はアイテム「Ｂ」を有する。例えば、「cat」は「fur」「sharp teeth」および「claw」を有する。
Link: アイテムＡは参照されたアイテムＢに従事、起動、または責任を負うという意味で、アイテム「Ａ」はアイテム「Ｂ」を行う。例えば、「cat」は「eat」「nap」および「meow」する。
Related: 類似または社会的条件がアイテムＡを何らかの方法でアイテムＢに関連付けるという点で、アイテム「Ａ」はアイテム「Ｂ」と同調する。例えば、我々の社会では、「cat」は「dog」「mouse」および「jazz」（即ち、「cool」 cat および 「hep」 cat）と関連する。これは連想リンクの最も弱いカテゴリであるが、広い概念検索において極めて有用である。加えて、アイテムは、類似または類似性（例えば、単一の言語シノニム、または複数言語用語等価）により「related」される。
関連するアイテムへの全ての参照を分類することの長所は、一般に、ブール論理積演算を使用してベクトル・キーの論理積を決定するＫｎＯＳ「プーリング」オペレーションで合致しなければならないベクトル・キーの数を本質的に減少させることである。
例えば、薬品試験所は、抗菌薬感受性に対して組織標本を試験する。これらの試験のデータ・インスタンスは名前無しである。何故ならば、試験がリレーショナル・モデルの連想リレーションだからである。試験所のコンピュータ・システムは、「人工的な」名前を各試験に対して、例えば、料金請求目的のために与える。特定の試験に対する人工的な名前は「23A-3&44-2121222-Jason」であり、ＫｎＯＳは所定の人工的な名前を試験アイテムのデータ・インスタンスとして記録する。しかし、このデータ・インスタンスを知り、思い出し、認識するユーザがいないので、アクセスをサポートする値はない。代わりに、試験データ・インスタンス = 「23A-3&44-2121222-Jason」を配置しようとするユーザは、出来れば識別に近づくように十分な手掛かりを与えなければならない。例えば、ユーザは、2002年7月12日に「Jason Lee」によって行われた試験を見ることを求める。２つの手掛かりと一緒に提出されたそのクェリは、ゼロ、１、または多くの考えられる結果を生成する。 Jason が7月12日に行った全ての試験をユーザが見るとき、シークしているものを突き止めることが出来る。この実施例では、試験を行う試験所の技術者および日付は「parent」リンクとして分類される。2002年7月12日の Jason Lee の試験を探すとき、ＫｎＯＳだけが試験アイテムの「parent」ＶＫセットを Jason および 2002年7月12日の「child」ＶＫセットと一緒に「pool」して、ベクトル・キーの一致を見付けなければならない。
実際には、関連型に対する分類の任意のマッピングは、ＫｎＯＳによりサポートされる。上記にリストされた４つの型は図示が目的であり、 human メモリに対して基本的であるが、コンテキストによる連想のグループ化を以下に考えるかに対する単なる示唆である。
今、関係次元の正確な意味論的コンテキストを考慮する。リレーショナル・モデルの殆どの専門家は、スキーマを設計し意味論的コンテキスト（ビジネス・ルール）を記録するために Peter Chen のエンティティ−関係モデルを使用する。殆どの場合、 ビジネス・ルールは、「is」または「has」である。質問は、意味論的コンテキストが実際には有益かどうかである。図８「データ表示の比較」に示される意味論的モデル等価物を考える。
Figure 2005534121
上記各々の場合、意味論的コンテキスト（ビジネス・ルール）は、「is」および「has」とサブジェクト（または、ターゲット値）の組合せである。この実施例は、リレーショナル・モデルの全実世界インプリメンテーションの大部分で真を保持し、それが非商用ＲＤＢＭＳが意味論的コンテキストをＥ−Ｒモデルから実施する理由である。この意味論的コンテキストは連想を分割または分類するための良い候補ではなく、それはサーチされなければならない関連のベクトル・キーのボリュームを減少させることが出来ないことを意味し、ＤＢＭＳの性能に対する利益がないことを意味する。しかし、以下のように意味論的コンテキストを再分類することは、著しい性能向上をもたらすことが出来る。
Figure 2005534121
辞書システムおよびＡＳＣＩＩ変換:
辞書システムはＡＳＣＩＩのために記憶されたリストを維持する独立型リポジトリであり、ＡＳＣＩＩセット（１−２５５）の全ての文字、従って、アルファベットの全ての文字（大文字および小文字）に対して、単一の桁数（0, 1, 2, 3, 9）、等を含む。ＫｎＯＳ辞書システムが実施できる多くの異なる方法が存在する。また、追加できる辞書の数には、理論的限界が存在しない。全ての科学、言語、言語の句に対する新しいＡＳＣＩＩ辞書を追加できる。また、ユニコードの辞書も、一連の知識に基づくアジア言語または他の複雑な文字セットのサポートで実施できる。加えて、辞書は、任意のトークン、記号セット、および任意の値セットを実施するために創出できる。以下はＡＳＣＩＩインプリメンテーションの１つの型であり、アーキテクチャの長所を図示するが、可能な辞書インプリメンテーション方法または技術の範囲または多様性を制限するものではない。
図１５「ＡＳＣＩＩ変換」に示されるように、リポジトリ #6 へのアクセスが、各アイテムのデータ・インスタンスのＡＳＣＩＩ値の最初の２つの文字に基づくときに十分早いことが明らかになる。もしその仮定が誤りであると証明されていたら、アイテムのデータ・インスタンスの更に多くの文字がインデックス化される。その結果、２つの辞書コンテキストは、環境 #1, リポジトリ #6 （コンテキスト #1 および #2）の内部に配置される。第１のコンテキストは全コンテキスト名およびリポジトリのアイテム・データ・インスタンスの第１の文字に割り当てられ、第２のコンテキストは全コンテキスト名およびアイテム・データ・インスタンスの全ての第２の文字に割り当てられる。２つの辞書コンテキストに対する多次元参照は、 {1,6,1,0} および {1,6,2,0} である。
各辞書コンテキストは、正確に２５５個のアイテムを有する。ＡＳＣＩＩ文字はベース１０の整数０−２５５に変換される必要はない、何故ならば、８ビットＡＳＣＩＩ文字は、「00000000」から「11111111」の８ビットバイナリ整数（または、ベース１０の０から２５５）として自然に読み込まれるからである。ベース１０の数字０−９は、ＡＳＣＩＩ文字 #48 - #57 である。アルファベットの２６個の大文字はＡＳＣＩＩ文字 #65 - #90 であり、小文字は #97 - #122 である。「Duane Lewellyn Nystrom, Esq.」の最初の２つのＡＳＣＩＩ文字（即ち、大文字「Ｄ］および小文字「ｕ」）は、各々ＡＳＣＩＩ文字６８および１１７である。
データ・インスタンスが「Duane Lewellyn Nystrom, Esq.」であるアイテムが人間コンテキストにベクトル・キー {1,38,1,5} を用いて追加されるとき、アイテムのデータ・インスタンスの最初の２つの文字に対するベクトル・キーも各２つの辞書コンテキストに追加される。データ・インスタンスが「Duane Lewellyn Nystrom, Esq.」（即ち、 {1,38,1,5}）であるベクトル・キー・アイテムは、各２つの辞書コンテキストに大文字「Ｄ」（{1,6,1,68}）および小文字「ｕ」（{1,6,2,117}）に対する「child」ＶＫセットの内部で各々追加される。換言すれば、アイテム {1,6,1,68} および {1,6,2,117} は、「child」ＶＫセットの内部でベクトル・キー {1,38,1,5}を各々含み、アイテム {1,38,1,5} は「parent」ＶＫセットの内部でアイテム {1,6,1,68} および {1,6,2,117} に対するベクトル・キーを含む。
ＫｎＯＳベクトル・キーを「Duane Lewellyn Nystrom, Esq.」に対して検索する第１のステップは、ＫｎＯＳアイテムを、ＡＳＣＩＩ大文字「Ｄ」 {1,6,1,74} および ＡＳＣＩＩ小文字「ｕ」 {1,6,2,117} に対してコンテキスト {1,6,1,0} および {1,6,2,0} から各々検索することである。多くの異なるコンテキストからの多くのアイテムは、ＡＳＣＩＩ大文字「Ｄ」から始まり、多くの異なるコンテキストからの多くのアイテムはＡＳＣＩＩ小文字「ｕ」をアイテムのデータ・インスタンスの第２の文字として有する。しかし、ずっと少ないアイテムは両方の条件を満たし、更に少ないアイテムは人間コンテキスト, {1,38,1,0} に属する。
ＡＳＣＩＩ大文字「Ｄ」およびＡＳＣＩＩ小文字「ｕ」に対するＶＫセットは、制御としてターゲット・コンテキスト （E,R,C,I} = {1,38,1,0} を有するベクトル・プールに配置される。プーリング・オペレーションは、フォーム {1,38,1,X} の何れのベクトル・キーが両方のＶＫセットに含まれるかを決定する。 {1,38,1,X} 制御要素（この場合には {1,38,1,5}）に対応する２つのＶＫセットの小さい方にある一番下のベクトル・キー要素で始めると、ＫｎＯＳは一致を探す他のＶＫセットの最適化された２分木検索を行う。もし一致が見付かれば、図示されるように、値が答えプールへ動かされる。このサーチは、２つのＶＫセットの小さい方の制御フォームの全要素がターゲットＶＫセットでサーチされるまで継続する。図１５に示される実施例では、２つのベクトル・キーはプール基準（ {1,38,1,5} および {1,38,1,24} ）に一致する。
次のステップは、参照されたフェッチを２つのアイテム {1,38,1,5} および {1,38,1,24} の各々に発行することである。これは２つのアイテムを、１つはデータ・インスタンス = 「Duane Lewellyn Nystrom, Esq.」と一緒に、１つはデータ・インスタンス = 「Duane Lee Guy, Jr.」と一緒に戻す。複数ＡＳＣＩＩ値での単純な文字列比較が、「Duane Lewellyn Nystrom, Esq.」の広域的ベクトル・キーが {1,38,1,5} であるという所望する結果を与える。これは、ＡＳＣＩＩ変換と呼ばれるプロセスを完了させる。
辞書インプリメンテーションの他の方法は、コンテキストのＡＳＣＩＩ符号化アイテムの単一のセットから成る。ＡＳＣＩＩ文字を構成するデータ・インスタンスを有する各アイテムに対して、ＶＫセットとして埋込要素に索引を付けられ、第２の他の文字インスタンス発生を表すＡＳＣＩＩの１または複数のセットが使用される。これは、第１の文字の要素としての発生により既にフィルタをかけられた第２、第３、および以降の文字の連想を有する従来の方法を超える長所を有し、プーリング・オペレーションは第３および以降の文字でだけ行われる。
ＫｎＯＳオペレーション:
図１０「ＫｎＯＳオペレーション」は、如何にしてＫｎＯＳが、図１に示されるリレーショナル・モデル・オペレーションと比較されるコア・オペレーションを行うかの実施例を示す。答えられる仮定の質問は、「全 stock orders の white beans の総額は幾らか？」である。リレーショナル・モデルは、この質問に（１）「Stock-Order」リレーションからの射影「Stock」および「Qty」、（２）「Stock」リレーションから「White Beans」を選択、（３）射影と選択の結合により答える。結果は拡張され、合計されて $53.80 を得る。
上記のリレーショナル議論は、索引付けの議論を除外している。ＫｎＯＳに対して、索引付けオペレーションは、辞書コンテキストで行われるＡＳＣＩＩ変換から「White Beans」に対するベクトル・キーを決定すること、および Stock コンテナを用いて検索されたアイテムのＶＫセットを「プーリング」することを継続する。プロセスは図１５「ＡＳＣＩＩ変換」に図示され、上記に記述される。いったん「White Beans」に対するＫｎＯＳベクトル・キー {0,6,1,3} がＡＳＣＩＩ索引付けオペレーションから決定されたら、ＫｎＯＳは同じ質問に参照されたフェッチを用いて以下のように答える。
ステップ #1 - どの stock-orders が white beans のためのものか？データ・インスタンス = 「White Beans」を有するアイテム {0,6,1,3} を「Stock」コンテナからフェッチする。アイテム {0,6,1,3} から「Stock-Order」コンテキストへの任意のＶＫセット参照（フォーム {0,6,3,X} のベクトル・キー、即ち {0,6,3,1} & {0,6,3,5} ）を抽出する。
ステップ #2 - 関連する量は何か？アイテム {0,6,3,1} & {0,6,3,5} を「Stock-Order」コンテキストからフェッチし、「Qty」コンテキストへの任意のＶＫセット参照 {0,6,5,X} を抽出する。答えは、それぞれ {0,6,5,1} & {0,6,5,3} である。 {0,6,5,1} & {0,6,5,3} を「Qty」コンテキストからフェッチし、データ・インスタンス「１」および「３」を各々が有するアイテムを得る。
ステップ #3 - white beans の価格は幾らか？ （上記（１）から ...）アイテム {0,6,1,3} から 「Price」コンテナへのＶＫセット参照を抽出する（フォーム {0,6,2,X} のベクトル・キー、即ち、 {0,6,2,3} ）。アイテム {0,6,2,3} を「Price」コンテナからフェッチして、データ・インスタンス「$13.45」を有するアイテムを得る。
ＫｎＯＳ結果は拡張され、合計されて $53.80 を得る。アイテム {0,6,2,3} をフェッチするステップは、参照されたフェッチである。何故ならば、アイテム {0,6,2,3} は、参照およびＫｎＯＳアドレスの両方だからである。
上記のことは、要求された情報を直接的にルックアップすることにより行われる。また、ＫｎＯＳは、「プーリング」と呼ばれるこのオペレーションの僅かに異なるバージョンも有する。「 Pinto Beans に対してどの stock-orders が Qty <= 2の Qty を有するか？」のような更に困難な質問をすると仮定する。この質問に答えるオペレーションが、図１１「プーリングの実施例」に示される。「プーリング」オペレーションでは、ＶＫセットがデータベースから所定の選択基準 （stock-orders, Pinto Beans, Qty <= 2）を使用して抽出され、ブール演算を使用しての直接的な整数の比較のために「pool」に配置される。第１のステップは、 Qty コンテキストからデータ・インスタンス <= 2 であるそれらのアイテムを検索し、「pool」に配置することである。次に、「Pinto Beans」に対する Stock コンテキスト・アイテムから検索し、「pool」に配置する。最後に、 Stock-Order コンテキストのベクトル・キー（即ち、 {0,6,3,0} ）を検索する。整数比較をベクトル・キーの最初の３つの構成要素（即ち、 {E,R,C}）で「フィルタリング」として知られるプーリング・オペレーションを使用して行い、結果（この場合には {0,6,3,X} ）を得る。整数比較の結果 {0,6,3,2} は、質問に対する答えである。
物理的媒体上でのデータのロケーション：
ＫｎＯＳインプリメンテーションの各リポジトリは、ディスク・ベース（または、メモリ・ベース）のシステムのファイルに類似するコンテナとして記憶される。アイテムのベクトル・キーだけが、それを物理的媒体に配置するために必要である。もしアイテムのベクトル・キーが既知でなければ、（図１５「ＡＳＣＩＩ変換」、および上記に記載の）ＡＳＣＩＩ変換プロセスを使用して最初に決定しなければならない。図１６「アイテム {0,6,8,2} を物理的媒体に配置」に示されるように、アイテム（例えば、 {0,6,8,2} ）をそのベクトル・キーに基づいて検索するための６つのステップが存在する。
ステップ #1 - コンテキスト・インデックス。リポジトリ・ファイルから検索する第１のデータベース・アーティファクトは、（この場合には、リポジトリ #6 のための）リポジトリのコンテキスト・インデックスである。コンテキスト・インデックスは順序付けられた一連の２つの部分から成るエントリを含み、１つのエントリは特定のリポジトリの全てのコンテキストに対する。コンテキスト・インデックス・エントリの第１の部分は、リポジトリの内部のコンテキストの実際の数であり、ベクトル・キーの「Ｃ」次元である。ここに示される最初の４つのエントリは、リポジトリ #6 の最初の４つのコンテキスト（コンテキスト #1, #2, #7 および #8）を表現する。コンテキスト・インデックスは順序付けられているので、図１６の実施例から、コンテキスト #3, #4, #5 および #6 は何らかの理由で削除されるか、単に決して追加されないことが明らかである。コンテキスト・インデックス・エントリの第２の部分は、コンテキスト・ロケータの一連の各コンテキストである。エントリの第２の部分は、リポジトリ #6 のコンテキスト #8 はコンテキスト・ロケータの第３のコンテキストであることを示す。
ステップ #2 - コンテキスト・ロケータ。リポジトリ・ファイルの次のアーティファクトはコンテキスト・ロケータと呼ばれ、コンテキスト・ロケータはコンテキスト・インデックスと同じ正確な物理的構造を有する。類似のコンテキスト・インデックス、コンテキスト・ロケータもリポジトリの各コンテキストに対する２つの部分から成るエントリを有するが、コンテキスト・ロケータは順序付けられたリストではない。コンテキスト・ロケータはコンテキスト・インデックスにより索引を付けられたリストである。上記のステップ #1 は、リポジトリ #6 のコンテキスト #8 がコンテキスト・ロケータ・リストの第３のコンテキスト・エントリであることを決定する。コンテキスト・ロケータ・リストのコンテキスト #8 のエントリの第１の部分（即ち、「#1」）は、コンテキスト #8 が直ぐにコンテキスト #1 を物理的媒体上で処理することを示す。コンテキスト・ロケータ・エントリの第２の部分は、コンテキスト #8 がリポジトリ・ファイルのコンテキスト・セクタの第５の「ページ」で始まることを示す。これもまた、「５のオフセット」と呼ばれる。ページ・サイズは、データ・オブジェクト細分性および殆どのＫｎＯＳオブジェクトの平均サイズに関するリポジトリ管理に対して最適であるように定義される。無駄なスペースを最小限にし、アクセス処理能力を最大にし、動的可変長アイテムを扱うために、非常にきめ細かいアプローチが一般に使用される。しかし、ページ・サイズは、どの様な記憶媒体が使用されても、およびどの様なデータ・オブジェクト・サイズが一般的であっても実行時において適合するように、および読み出し専用のデータマート、またはデータマイニング・アプリケーション、またはトランザクション毎に更新される多くのアイテムを有するリアルタイム動的データ・モデルの何れでもＫｎＯＳの主要な目的に適合するように定義される。マルチメディア・アプリケーションでは、大きなデータ・オブジェクト（例えば、イメージまたは音ファイル）が、典型的なページサイズを定義する。アプリケーションとは関係なく、１つの規則はどの２つのＫｎＯＳオブジェクトも（コンテキストまたはアイテムの何れでも）同じページの内部に含まれると言うことである。もし所定のオブジェクトがページを満たさなければ、ページの残りは空白のまま残される。
ステップ #3 - コンテキストＢＬＯＢ。リポジトリ #6 の各コンテキスト、および各コンテキストの各アイテムは、リポジトリ #6 の物理的媒体にＢＬＯＢとして記憶される。上記ステップ #2 で得たロケーション（即ち、「５のオフセット」）に基づいて、リポジトリのコンテキスト・セクションの第５のページで始まるディスクのトラック／セクタをバッファする。バッファされたディスクトラック／セクタは、コンテキスト #8 により占められた４ページよりも多い情報を含むであろう。コンテキスト #8 に対するヘッダは、リポジトリのファイルのコンテキスト・セクションの第５のページで始まる。最初の４ワードはコンテキストのベクトル・キー（この場合には {0,6,8,0} ）であり、コンテキストのアイテム・マップが続く。コンテキスト #8 に対するアイテム・マップは、コンテキストの内部が配置されたアイテム・インデックス、およびアイテム・ロケータであることを示す。これら２つのリストは、構造およびコンテキスト・インデックスおよびコンテキスト・ロケータに対する目的が類似する。
ステップ #4 - アイテム・インデックス。コンテキスト #8 のアイテム・マップに基づいて、コンテキストのアイテム・インデックスをコンテキスト #8 ＢＬＯＢから検索する。アイテム・インデックスは、順序付けられた一連の２つの部分から成るエントリを含み、１つのエントリは特定のコンテキストの全てのアイテムに対するものである。アイテム・インデックス・エントリの第１の部分はコンテキストの内部のアイテムの実際の数であるか、またはベクトル・キーのＩ次元である。ここに示される最初の４つのエントリは、コンテキスト #8 の最初の４つのアイテム（アイテム #1, #2, #5 および #6）を表現する。アイテム・インデックスは順序付けられているので、図１６の実施例から、アイテム #4 および #5 が削除されたことが明らかである。アイテム・インデックス・エントリの第２の部分は、アイテム・ロケータの一連の各アイテムである。エントリの第２の部分は、コンテキスト #8 のアイテム #2 がアイテム・ロケータの第３のアイテムであることを示す。
ステップ #5 - アイテム・ロケータ。コンテキストＢＬＯＢから検索する次のアーティファクトはアイテム・ロケータと呼ばれ、アイテム・ロケータはアイテム・インデックスと同じ正確な物理的構造を有する。アイテム・インデックスと同様に、アイテム・ロケータもコンテキストの各アイテムに対して２つの部分から成るエントリを有するが、アイテム・ロケータは順序付けられたリストではない。アイテム・ロケータは、アイテム・インデックスにより索引を付けられたリストである。上記のステップ #4 は、リポジトリ #6 のコンテキスト #8 のアイテム #2 がアイテム・ロケータ・リストの第３のアイテム・エントリであることを決定する。アイテム・ロケータ・リストのアイテム #2 のエントリの第１の部分（即ち、「#6」）は、アイテム #2 が直ぐにアイテム #6 を物理的媒体上で処理することを示す。アイテム・ロケータ・エントリの第２の部分は、アイテム #6 がリポジトリ・ファイルのアイテム・セクタの第７の「ページ」で始まることを示す。これもまた、「７のオフセット」と呼ばれる。また、ページ・サイズは、殆どのＫｎＯＳオブジェクトのサイズに対して最適なように定義される。何故ならば、どの２つのＫｎＯＳオブジェクト（コンテキスト、またはアイテムの何れか）も、同じページに含まれないからである。もし所定のオブジェクトがページを満たさなければ、ページの残りは空白のままにされる。
ステップ #6 - アイテムＢＬＯＢ。コンテキスト #6 の各アイテム、およびリポジトリの各コンテキストは、リポジトリ #6 の物理的媒体上にＢＬＯＢとして記憶される。上記ステップ #5 で得られたロケーション（即ち、「７のオフセット」）に基づき、リポジトリのアイテム・セクションの第７のページで始まるディスクのトラック／セクタをバッファする。バッファされたディスクのトラック／セクタは、アイテム #2 により占められる２ページよりも多い情報を保持する。アイテム #2 に対するヘッダは、リポジトリのファイルのアイテム・セクションの第７のページで始まる。いつものように、オブジェクトの最初の４ワードはアイテムのベクトル・キー（この場合には {0,6,8,2} ）であり、アイテムのアイテム・マップが続く。
これは、アイテム {0,6,8,2} を物理的媒体に配置するのに必要なステップを完了させる。前記６つのステップは、物理的媒体アクセスの論理的議論であることを銘記する。（ステップ #3 からの）コンテキストＢＬＯＢ、および（ステップ #6 からの）アイテムＢＬＯＢは、「オフセット」目的の別々のファイル・セクションとして考えられる。実際には、図１６に示される６つのＫｎＯＳオブジェクト全てが、リポジトリ #6 であるファイルの内部の同じ隣接する物理的媒体で索引を付けられる。コンテキストおよびアイテムは構造が非常に類似して見え、オブジェクト・ヘッダの「オブジェクト型」により区別される。また、「オフセット」（ロケータ）は「有効アドレス」であり、参照されたページＩＤは記憶媒体の内部アーキテクチャによって間接的に導出される。
物理的媒体の更新：
ＫｎＯＳ「リポジトリ」は、ＢＬＯＢのファイルから成る。図１６「アイテム {0,6,8,2} を物理的媒体に配置」に示されるように、ＢＬＯＢは参照によって独立にアクセスされる。図１９および図２０「アイテム {0,6,8,2} を物理的媒体上で更新する−Ｉ＆ＩＩ」に示されるように、コンテキストＢＬＯＢおよびアイテムＢＬＯＢは、リポジトリ・ファイルで混合され、特定の順序にはない。ＢＬＯＢは、効率的運用のためＫｎＯＳに順番に並ぶことを要求しない。何故ならば、全ての必要な情報は、各ＢＬＯＢでカプセル化されたからである。順序独立性は、ＫｎＯＳがカプセル化の特定のフォームから得る中心的長所の１つである。ＫｎＯＳデータ構造の各ＢＬＯＢは、ロケーションに対して索引を付けられる。ディスク上の一連のＢＬＯＢは、ＫｎＯＳオペレーションの結果ではない。何故ならば、各ＢＬＯＢは、その特定のＢＬＯＢに対して関連する適切な全知識を用いて完全にカプセル化されるからである。
各ＢＬＯＢ（コンテキストまたはアイテムの何れか）はディスク上に配置された特定の数のページに割り当てられるので、各ＢＬＯＢの最後のページは空白スペースを含む。ページ・サイズは、ページ上に出来るだけ少ない空白スペースを有する１ページ上に殆どのＢＬＯＢを収容するように確立される。好ましい実施例では、ページ・サイズはアプリケーションの最適化要求、平均ＢＬＯＢサイズ、およびＢＬＯＢが記憶される物理的媒体の構造化された性質に基づいて決定される。
全ＢＬＯＢは、各更新によりサイズが増減する。もし更新の後に、ＢＬＯＢがページの割り当てられた数字をまだ要求していたら、更新された形式でディスクに書き戻され、ページの同じブロックに書き戻される。もし更新の後に、ＢＬＯＢが以前のページ割当よりも多い（または、少ない）ページを要求したら、ＫｎＯＳがディスクを更新するのに必要な最小仕事を評価する。ＢＬＯＢの多様なサイズは、アプリケーションによって変化する。一般に、ＢＬＯＢが大きくなるほど、それを動かすのは好ましくない。もし拡張したＢＬＯＢが（それ自体のスペース）＋（次のＢＬＯＢに対して配置されたスペース）にまだ適合するなら、拡張したＢＬＯＢは元のオフセット位置に戻され、次のＢＬＯＢを過程の外へ動かす。
ＫｎＯＳは、アイテムのベクトル・キーを占めているロケータ内部へ関連するインデックスを用いて、ページＩＤ参照により割り当てられた全ての隣接するページ・ブロックのメモリに常駐する「registry」を維持できる。全てのアイテムのこの物理的−論理的マッピングは、完全連想モデルを使用して実施されるメモリおよびディスク管理の異なるスキームを可能にし、１つはＫｎＯＳの内部に全体が含まれ、従って、１つは第三者にディスク・オペレーティング・システム（または、メモリ管理システム）を動作させることを要求しない。
追加空白スペース管理コンテキストが、データ・インスタンスが利用可能な隣接するページの数である１組のアイテム（例えば、データ・インスタンスが「１」に等しいアイテムは、全１ページ割当のリストである、等）を用いて各リポジトリで例示でき、各アイテムは、ＶＫセット、ページ・ロケータ参照を、サイズ が各アイテムのデータ・インスタンスであるリポジトリ・ファイルの使用された部分の内部で、割当解除された全ての隣接するページ・ブロックへの索引として有する。
もしＢＬＯＢサイズ増加および減少の多少の配布があれば、以下のスペース・レジストリ・スキームが好ましい。
このインプリメンテーションでは、ＫｎＯＳは単に更新されたＢＬＯＢをディスクに再配置する。これを行うために、ＫｎＯＳは、空白スペース・コンテキストの（データ・インスタンスが更新されたＢＬＯＢに要求されたページの数である）アイテムに索引を付ける。そのアイテムのページＩＤ参照リストから、要求されたページ数の最後に追加された隣接するページ・ブロックのページＩＤを得て、更新されたＢＬＯＢを新しいロケーションにコピーし、ＢＬＯＢアイテムに対する適切なロケータ参照を更新し、ページＩＤを空白スペース・コンテキストのアイテムのページＩＤ参照リストから削除する。次に、ＫｎＯＳは、以前に占められたページ・ブロックを、（ＩＤがページ数である）空白スペース・コンテキストのアイテム、ページＩＤ参照リストに追加する。
例えば、もしＫｎＯＳオブジェクトが現在５ページを要求しており、７ページを要求するために更新されたら、ＫｎＯＳは最初にスペース・レジストリをチェックして、隣接する７ページを有する利用可能な「オフセット」が存在するかを見る。もし存在したら、ＫｎＯＳは（ａ）利用可能な７ページのオフセットの１つを取り、（ｂ）新しいスペースをスペース・レジストリから削除し、（ｃ）更新されたＫｎＯＳオブジェクトをそのロケーションに書き込み、（ｄ）エントリの後半をコンテキストまたはアイテム・ロケータの何れかにおいて新しいオフセット・ロケーションを用いて更新し、（ｅ）古い空の５ページ・オフセット・ロケーションをオープン・スペース・レジストリに追加する。もし要求された正確なページ数の利用可能なオープン・スペースが無ければ、図１９に示されるように、ＫｎＯＳは更新されたオブジェクトをファイルの終わりに付加する。
時間が経つとこのディスク管理スキームを用いて、割当解除されたページの中には、リポジトリ・ファイル全体に発展するものもある（図１９の実施例を参照）。全ディスク・スペースが問題でない限り、これらのホールは問題をＫｎＯＳに提示しない。ＲＤＢＭＳとは異なり、ディスクが混乱するにつれてＫｎＯＳ処理能力効率が著しく低下しない。ディスク上の一連のＢＬＯＢは、アクセス・スキームに対して重要ではない。ＫｎＯＳに関する限り、ディスク・ファイルは本来的に混乱している。
もしディスク稼働率が顧客に対して許容できない低さになれば、ＫｎＯＳはバックグラウンド・オペレーションを開始し、ＢＬＯＢの間で割当解除された任意のページを削除する方法で、リポジトリのＢＬＯＢを新しいファイルへコピーする。参照ＩＤにより為される、ＢＬＯＢを順番に配列する試みは無い。しかし、ＢＬＯＢは、コンテキストの内部でのアイテムＩＤ順序に従ってコピーできる。これは、全アイテムをリポジトリで線形化し、もしコンテキスト・コンテンツがリポジトリからそのまま要求されることが多ければ、ディスク・ヘッド・シークタイムを減少させることが出来る。さもなければ、既存のＢＬＯＢ順序が新しいディスク領域にコピーされる。コピーの目的は、ＢＬＯＢを端と端を接して配置し、ＢＬＯＢの間の割当解除された任意のページを削除することである。これは、ＫｎＯＳの現在のオペレーションを乱すことなく行われる。もし移動された任意のＢＬＯＢがオペレーティング・システムによりアクセスされたら、コピー・プロセスの終わりまで更新は単にキャッシュされ、キャッシュされた更新がディスクに書き込まれる。
他のスキームでは、図１９に示されるような「eviction」方法が使用される。この方法を用いて、割当解除されたページ問題は事実上存在しない。もし起動されたら、各アイテムが増大するにつれて、増大するのに必要なスペースは、過程の内外でスペースを占めるアイテムを、リポジトリの使用された部分の終わりの空白スペース、またはスペース・レジストリで見付かった適合サイズの空ページ・ブロックの何れかへ動かすことによって供給される。次に、もたらされたスペースが、増大したアイテムに割り当てられる。アイテムは殆どのアプリケーションで増大しようとするので、如何なる空白スペースもアイテムは過程をクリアすることにより得て、結局は増大を続けるアイテムになじむ。この方法では、アイテムを削除することにより残されたスペースは、メモリで処理するアイテムに割り当てられるか、または新しいか移動されたアイテムへの再割当のためにスペース・レジストリに追加されるかの何れかである。
コンテンツ・アウェアネス：
ＫｎＯＳインプリメンテーションは、キーワード・サーチ、および限定されたテキスト・サーチ機能を、構造化されたデータ・アプリケーションの中心的実施例の一部としてサポートできる。例えば、構造化されたデータ・アプリケーションを有する企業も、テキスト・サーチ、およびキーワード・サーチ機能を全従業員のレジュメに提供する要求を有する。以下は、それが如何にしてＫｎＯＳで行われるかである。
第１に、各人のレジュメは、人間アイテムの埋込アイテムとしてマルチ・ページＰＤＦ形式（Adobe システム）で追加される。次に、レジュメは、図１３「ＫｎＯＳアイテムの構造」の埋込アイテム（即ち、電話番号、および住所）と類似して出現する。レジュメのＰＤＦはＢＬＯＢとして単に記憶されるか、または各人間のアイテムの内側のＢＬＯＢと比較される。
第２のステップは、「Keyword」コンテキストを確立して配置することである。このコンテキストは、全レジュメの（結合、アーティクル、等でない）自明でない各ワードに対して１つのアイテムを含む。ワード自体は、キーワード・コンテキストの各アイテムに対するアイテムのデータ・インスタンスである。新しい（または、改訂された）レジュメが人間コンテキストに追加されるときはいつも、特定の人間に対する以前の全ての連想キーワード参照が削除され、レジュメの各々の特有の自明でない全てのワードに対する新しい連想参照がキーワード・コンテキストに追加され、もちろん、特定の人間のアイテムに対して双方向である。キーワード・コンテキストの各アイテムは、人間コンテキストの正しい人間アイテムに対するベクトル・キーを含む。例えば、もしレジュメ・ワードが「carpentry」なら、データ・インスタンス = 「carpentry」であるキーワード・アイテムは、ベクトル・キーの特定のＶＫセットを、レジュメにワード「carpentry」を有する全ての人間に対して含む。
テキスト・サーチをレジュメで行うために、ユーザはサーチのためにワードの文字列を入力しようとする。各サーチ・ワードは最初にＡＳＣＩＩに変換され、各サーチ・ワードに対するキーワード・アイテム・ベクトル・キーを決定する（これが如何に行われるかの実施例のために図１５「ＡＳＣＩＩ変換」を参照）。次に、各サーチ・ワードに対する正しいキーワード・アイテムが人間コンテキストと一緒に「プール」され、どの人間アイテムがそれら正確なワードをもつレジュメを有するかを決定する。この手続きは、図１１「プーリングの実施例」に示された「プーリング」オペレーションと同じである。プーリング・オペレーションの結果は、レジュメが全てのサーチ・キーワードを有する全ての人間に対するベクトル・キーのリストである。人間データ・インスタンスのリストはユーザに戻るか、または人間アイテムの単純な検索は実際のレジュメを埋込ＰＤＦとして生成する。
ＰＤＦ形式のレジュメを各人間アイテムに追加することは、相当なサイズを各人間アイテムに追加する。もし人間アイテムの日常的使用がレジュメを要求しないなら、レジュメの実際のＰＤＦをレジュメと呼ばれる別々のタグ・セット・コンテキストに埋め込むことが処理能力効率のために有利である（タグ・セット・コンテキストの説明は以下を参照）。次に、実際のレジュメＰＤＦは必要なときだけ検索され、個人アイテムが検索される各時間には検索されない。実際には、これは、何かが埋込アイテムとしてベース・アイテムに含まれるべきかどうかの一般化された試験の一部である。
旧式のデータベースをＫｎＯＳデータベースに同化する：
実際問題として、殆ど全部の企業がデータの旧式のリポジトリをテーブル形式でもっている。ＤＢＭＳとしてのＫｎＯＳ発明の有用性は、テーブルに記憶された多量の旧式のデータを吸収し同化する機能により大部分が判断される。大体は、この旧式のデータは調整されていない単層ファイルに存在し、理想的な正規（３ＮＦ）形式には存在しない。ＫｎＯＳは、完全に正規化されたリレーショナル構造を吸収したときに最も良く機能する。
１組の正規化された（３ＮＦ）リレーショナル構造、および関連するデータは、うまく定義されたプロセスによりＫｎＯＳコンテキストおよびアイテムへ変換または同化できる。リレーショナル・データベースは３つの型の正規化されたリレーション（テーブル）（命名された（主リレーション）、命名されない（連想リレーション）、およびルックアップ）から成り、各々はＫｎＯＳへ 別々に同化される。このセクションは最初に、如何にして図１「リレーショナル・データ・モデル」に示されるリレーショナル・データベースがＫｎＯＳに同化されるかを記載した。殆どの旧式のアプリケーションは（リレーショナル・テーブルではない）単層ファイルを使用するので、セクションの残りは、如何にして単層ファイルが処理されて、あたかもリレーショナル・データベースかのように同化目的をカバーするかを記載する。
命名された（主要な）リレーションを同化する：
名前は、リレーション（テーブル）の各タップル（行）に与えられる特有の識別子である。名前として適格であるものに対して、それは特有でなければならず、ユーザがそれを識別できなければならない。ユーザが命名できるリレーショナル・タップルがあり、他は命名できないことは紛れもない事実である。これは、ユーザが命名するには複雑すぎるリレーションがあるからである。命名されないタップルは、手掛かりをそれらの存在に与えることによってのみ記述できる。
リレーショナル・モデルでは、命名されたリレーションは最も頻繁に呼ばれる主リレーションである。命名されたリレーションの特別な場合、ルックアップ・リレーションは、主リレーションとは考えられない。これらに対して、以下の「ルックアップ・テーブルの同化」のセクションを参照。図１−図２では、 Stock 主リレーションは命名されたリレーションであり、そのタップルは「Pinto Beans」、「Kidney Beans」、「White Beans」および「Wax Beans」と命名される。命名されたリレーションの他の全ての特有の列は、１つの列として各コンテキストに同化される。以前に記載したように、ＫｎＯＳコンテキストは、リレーショナル列または属性に類似する。
図３に示されるように、 Stock 主リレーションは２つのＫｎＯＳコンテキスト（１つのコンテキストは「Stock」属性に対して、１つのコンテキストは「Price」属性に対して）同化される。もしより多くの属性が Stock リレーションに存在したら、特有の各属性はそれ自体のコンテキストをＫｎＯＳに有する。もしコンテキストが同じなら、属性はＫｎＯＳと特有の基準に基づいて同化する。もし 「Price」属性が同じ関係コンテキスト（例えば、何かの価格）の４つの異なるリレーションに出現したら、ＫｎＯＳは１つの「Price」コンテキストだけを有する。次に、 Stock 主リレーションの各タップルは、ＫｎＯＳの命名された属性コンテキスト（この場合には、「Stock」コンテキスト）のアイテムに割り当てられる。命名された各行は、アイテムを命名されたコンテキストに有しなければならない。図２に示されるように、 Stock リレーションの４つの行は「Stock」コンテキストの４つのアイテムを意味し、１つは命名された各アイテムに対するものである。主リレーションの他の全ての属性に対して、１つのＫｎＯＳアイテムは属性の特有の各値に対して創出される。「price」属性に対して、異なる各価格に対する１つのアイテムが存在する。この場合、４つの価格は４つのアイテムを意味する。もし「Pinto Beans」および「Kidney Beans」の両方が１ケース当たり $11.10 かかれば、「Price」コンテキストは３つのアイテム（即ち、 $11.10, $13.45 および $18.72）だけを有する。
命名されたリレーションの各タップルは、多くの埋込関係を表現する。関係を各タップルの内部に記録するために、ＶＫセットは各コンテキストに挿入され、「Stock」および「Price」の間の関連を完全に記述する。完全な同化は、図５に示される。命名された各リレーションは、この方法で同化される。
命名されない（連想）リレーションを同化する：
リレーショナル・モデルでは、命名されないリレーションが最もよく呼ばれる連想リレーションである。何故ならば、それがリレーションの複雑な関連を記述するために使用され、ＦＫによって定義されるからである。その複雑さのために、一般に連想リレーションは個々のタップルを参照する便利な名前をもたない。図３「連想リレーションの同化」に示されるように、 Stock-Order リレーションは連想である。図８「データ表示の比較」の下部に示されるように、それは、命名された Stock （「Pinto Beans」、「Kidney Beans」、「White Beans」および「Wax Beans」）を命名された顧客注文番号 （#1111, #1117, #1118, および #1119）に関連付ける。連想リレーション Stock-Order は２つの命名されたリレーション（Stock および Order）を関連付けるが、それ自体は命名されたリレーションではなく、ユーザがリレーションの個々のタップルを直接的に命名できないことを意味する。
リレーショナル・モデルに対して、ＫｎＯＳ設計は、命名されたコンテキストに全てのリレーションに対してリレーションのタップルを表現することを要求する。だから、もし所定のリレーションが名前無し（タップルが単一のＰＫ属性によって一意に識別できない）ならば、ＫｎＯＳは別々のプロキシ命名されたコンテキストを特定のリレーションに要求する。図３に示されるように、ＫｎＯＳのプロキシ「Stock-Order」コンテキストは、（リレーショナル・タップルが名前無しであるのと同じ理由で）名前をアイテムにもたない。特別なプロキシ・コンテキストをリレーションに対して創出する以外に、命名されないリレーションは同一の方法で命名されたリレーションに同化される。
命名されたリレーションと命名されないリレーションの違いは、図２−図３で最も明らかである。命名されたリレーションは、１つのＫｎＯＳコンテキストとしてリレーションの全ての属性に対して別個のコンテキストを用いて同化され、命名されないリレーションは、１つのＫｎＯＳコンテキストとしてリレーションの全ての属性に対して＋１つのプロキシ命名されたコンテキストを命名されないリレーション自体に対して同化される。図３では、プロキシ・コンテキストは、コンテキスト #3 : Stock-Order である。
命名されないリレーションに対するいわゆるプロキシ・コンテキストは単なるリレーショナル・センスのプロキシであり、リレーショナル理論と比較して、それは命名されないリレーションに対するプロキシであることを銘記する。ＫｎＯＳに関しては、他の任意のコンテキストと区別がつかないのはコンテキストである。もし、リレーショナル・モデルを先例とせずに、データ・モデルを最初から創出したら、規則が当てはまらない。代わりに、ＫｎＯＳモデルは、１つの行のようなコンテキストを全ての概念に対して、および１つの列のようなコンテキストを別個のコンテキストを有する全ての属性に対して保持する。
連想リレーションは、リレーション自体を表現する１つのＫｎＯＳコンテキスト、およびリレーションの特有の各属性に対する１つのＫｎＯＳコンテキストに同化する。 Stock-Order リレーションは、プロキシ「Stock-Order」コンテキスト、およびリレーションの「Stock」「Order」および「Qty」属性に対する１つのＫｎＯＳコンテキストに同化する。図２と同様に、ベクトル・キーはＶＫセットに連結され、３つの属性をリレーションに関連付けるリレーションを反映するコンテナでカプセル化される。
図５「ＫｎＯＳコンテキストへの関係の同化」は、如何にして命名されたリレーション、および命名されないリレーションが同化の後にＫｎＯＳに出現するかを示す。図５の上部の２つのリレーションは、構造に関してアプリケーションに大きく依存する。図５のリレーショナル・リレーション下部の５つのＫｎＯＳ構造は全て同じであり、特定のアプリケーションに依存しない。各アイテムは同じ正確な物理的構造（ＶＫセット、および含有される任意のアイテム埋込要素が続く名前（または、名前プロキシ）を含むデータ・インスタンスが続く自己参照ベクトル・キー）を有する。
ルックアップ・リレーションを同化する：
リレーショナル・データベース設計は、属性レベル一貫性を、ルックアップ・リレーションと呼ばれる特別な命名されたリレーションにより達成する。ルックアップ・リレーションは、所定の属性に対して許容される値のドメインを記録するために使用される平凡なリレーションである。ルックアップ・リレーションは、２つの列（属性値に対するプロキシである人工的なキー（ＡＫ）、および属性データ値自体である名前）を有する。機能アプリケーション内部の許可は、誰が値を追加、編集、またはルックアップ・リレーションから削除できるかを制限する。ドメインを制限された属性を使用する各リレーションでは、ＡＫプロキシは常に属性データ値に取って代わる。
ルックアップ・テーブルは、ＫｎＯＳと同化する第１のものである。ＫｎＯＳがＡＫを同化しないと仮定すると、各ルックアップ・リレーションは、１つのＫｎＯＳコンテナに同化する。ルックアップ・リレーションを使用する命名されたテーブル、および命名されないテーブルがＫｎＯＳに同化されるとき、ＡＫプロキシ関係は、ルックアップ属性を表現するコンテナへの直接的関係を支持して削除される。
例えば、リレーショナル・アプリケーションは、ちょうど３つの値（「red」、「blue」および「green」）に対する属性「Color」を制限するために選択する。アプリケーションのユーザが他の色をリレーションに割り当てないことを保証するために、「Color」と呼ばれるルックアップ・リレーションが、ちょうど３つのタップル（「red」、「blue」および「green」）を用いて創出される。これらは、「１」、「２」および「３」の値を有するプロキシ属性「Color Code」（ＡＫ）を各々割り当てられる。リレーショナル・データベースの残り全体を通して、プロキシ属性「Color Code」{1,2,3}が、「Color」{「red」、「blue」、「green」}自体の代わりに使用される。
この実施例では、ＫｎＯＳは最初に、「Color」ルックアップ・リレーションをデータ・インスタンス = 「red」「blue」および「green」である３つのアイテムを有する「Color」コンテキストに同化させる。ＡＫ「Color Code」がリレーションの同化に遭遇するたびに、ＫｎＯＳは「Color Code」{1,2,3}ＡＫ属性を「Color」属性に対するＫｎＯＳベクトル・キーを支持して削除し、３つのアイテムの１つを「Color」コンテキスト{「red」、「blue」、「green」}で表現する。リレーショナル・データベースからの連想は保存されるが、ＡＫ「Color Code」はＫｎＯＳインプリメンテーションで生き残らない。ＫｎＯＳベースの機能アプリケーションは、誰が「Color」コンテキストでアイテムを追加、編集、または削除できる／できないかに関する類似した許可制御を設けなければならない。これは、ルックアップ・リレーションがリレーショナル・インプリメンテーションで遂行する同じ属性レベル一貫性を行う。
単層ファイルを同化する：
前記３つのセクションは、如何にして完全に正規化されたリレーショナル・データベースがＫｎＯＳに同化されるかを記載する。しかし、多くのデータベースのＫｎＯＳ形式への同化は、リレーショナル・テーブルではなく「単層ファイル」に由来する。また、単層ファイルはテーブルであるが、正規化（命名された、命名されない、またはルックアップ）のリレーショナル規則に従わない。単層ファイルは、特定のアプリケーションをサポートするユーザ「ビュー」によって代わりに編成される。その結果、単層ファイルは余りに混乱していて、直接的に同化できない。
ＫｎＯＳ形式に同化されるために、以下のセクション（正規化と呼ばれるリレーショナル・プロセス）に記載されるように、単層ファイルは最初にマークアップされなければならない。いったん各単層ファイルがマークアップされて、以下に記載するように準備されたら、以前のセクションに記載されるように、ＫｎＯＳ形式に同化される。ＫｎＯＳ形式に同化する前に、単層ファイルを準備して、リレーショナル・テーブルに分割する必要はない。マークアップは単層ファイルに適用されて、単層ファイルが、（命名された、命名されない、またはルックアップ）リレーショナル・テーブルのようにソフトウェアによって同化されることを可能にする。
以下のセクションは、リレーショナル・テーブルのように単層ファイルを解析およびマークアップするためのプロセスを記載する。単層ファイルを同化するために、ＫｎＯＳは以下に記載される単層ファイル・マークアップを読み込めるアシミレータ (assimilator) と呼ばれる１本の特殊目的のソフトウェアを必要とし、情報を単層ファイル形式からＫｎＯＳ形式に変換する。
不必要なデータを識別する：
単層ファイルを変換する第１のステップは、不必要なデータを識別することである。時間が経過するにつれて、単層ファイルに基づく任意のコンピュータ・システムはデータの不必要な列を要求する。もはやアプリケーション・ソフトウェアによって使用されない単層ファイルの内部の情報の列が存在する。データの不必要な列を識別する最も単純明快で正確な方法は、単層ファイルの種々の列への新しいユーザ・ビューの所望するセットの各要素をマップすることである。このプロセスは、ビューモデル化と呼ばれる。ビューは単層ファイルの情報（最も一般にはスクリーン、レポート、およびインターフェース）との任意のエンドユーザ対話である。この方法で、いったん単層ファイルが「ビュー」にマップされたら、単層ファイルの列の多くは要求される任意の機能にアンマップされそうである。単層ファイルのこれらの列は不必要なデータの候補であり、それらは同化されない。
不必要な列の初期マークアップは、情報が本当に必要でないことを確認するために、新しいアプリケーションのユーザによりチェックされなければならない。不必要としてマークされた殆どの情報は、色々な出来事に追い越された旧式のアプリケーションの属性である。情報は単層ファイルに配置され、以前のある時期に旧式のアプリケーションに役立つ。旧式のアプリケーションが変更されて機能が削除されるとき、単層ファイルは訂正されず未使用の情報を削除する。旧式のアプリケーションが古いほど、データの更に多くの不必要な列が単層ファイルに含まれる。
データの不必要な列候補は、情報を処理するための「単層ファイル」アプリケーション・ソフトウェアによって使用される物理的表示（フラグ、インジケータ、等）であることが多い。そのようのフラグ、およびインジケータは、新しいアプリケーションによって要求されてもされなくてもよい。そのようなフラグまたはインジケータの各々は、特定のフラグまたはインジケータが他の手段（新しいアプリケーションのソフトウェア）によって再確立できることを確認する新しいアプリケーションの挙動モデルと照合されなければならない。もしされなければ、フラグまたはインジケータを含む列が、同化のためにマークされなければならない。
導出されたデータを識別する：
第２のステップは、導出されたデータを識別することである。ユーザ・ビューにマップしない単層ファイルの情報の多くは、データの他の必要な列から直接的に導出できるデータ値である。導出されたデータ（例えば、数値の全列）は単層ファイルに配置され、コンピューティング・リソースの役に立つ。導出されたデータが新しいアプリケーションによって必要とされてもされなくても、それは決して同化されない。代わりに、導出されたデータはユーザのアプリケーションによって実行時において導出されるか、または、もし導出されたデータが記憶されたら、ＫｎＯＳによって同化の時に再度導出される。単層ファイルの導出されたデータの全ての列は、同化に対して不必要なように識別され、マークされなければならない。
ＫｎＯＳに記憶される導出された任意のデータに対して、ファイル・マークアップは、導出アルゴリズムを含まなければならない。アシミレータ・ソフトウェアの プリプロセッサは、導出されたデータをアルゴリズムから再現しようと試み、単層ファイルに含まれる導出されたデータに対する差異をリポートする。そのような差異は、差異が有効であること（即ち、アルゴリズムが正確であること）を保証するために、新しいアプリケーションのユーザによりチェックされなければならない。
複合情報を解決する：
ステップ３は、複合情報の解決である。単層ファイルの複合情報は、ソートおよび印刷のような特別な目的のために（または、特別なプロセッシング条件を起動するために）アトミック属性の連結から成る導出されたデータの形式である。複合情報のそのような各列は、解析されて解決されなければならない。複合情報の列は、単層ファイルの他の任意の列に出現しない必要なデータの１または複数のカーネルを含むことが多い。これらの場合、単層ファイルは前処理されて、情報の必要なカーネルを複合属性から抽出し、それを単層ファイルの新しい列に（同化目的で）配置する。いったん 必要なカーネルが単層ファイルの新しい列から抽出されたら、複合情報の列は不必要（および、同化されない）としてマークされる。
レコードコピーをマークする：
ステップ４は、複製を識別し、コピーまたはレコードをマークすることである。同化プロセスの最も異なる部分は、情報の複製された列の間の同期エラーに関する。単層ファイル全体の情報（属性）の列が、複製されそうである。複製された属性が同じ主キー値に対して異なる値を有するときはいつも、同期エラーが発生する。同期エラーは識別されなければならず、レコードのコピーは同化（即ち、異なる値の何れが正確か）に対してマークされなければならない。属性の残りの複製は、不必要である（および、同化されない）としてマークされる。
このプロセスの第１のステップは、複製された属性の主キーを識別することである。次に、ＫｎＯＳ同化プリプロセッサは、主キーの特有の各値を複製された属性の全ての値と比較しなければならない。理想的な状況では、主キーの単一の特有の各インスタンスに対して、全ての複製された属性は同じ値をもつべきである（これが、結局、複製の意味である）。プリプロセッサが多数の違反を見付けそうなこの条件をチェックするとき、複製は本当の複製ではない。コンピュータ化されていないプロセスが、これらの異なる値の何れが正確な値かを決定できる。主キーも誤って査定され、複製は本当の複製ではない（例えば、実際には、異なるアドレスは料金請求アドレス、送り状アドレス、等である）。これらの場合、複製された単層ファイル列に対して主キーを訂正することが、同期エラーを訂正する。
同期していない本当の複製に対して、アナリストはアプリケーションのユーザにより同期エラーを確認しなければならず、識別された各データの完全性エラーに対する処置を決定しなければならない。最善の結果は特定の複製された列がレコードのコピー（即ち、同化されるデータの列）であることを決定するユーザ人口に対するものであり、それにより他の全ての複製された列が不必要である（および、同化されない）としてマークされることを可能にする。ユーザは、各同期エラーが個々に解決されることを要求する。この解析の結果は、同化ソフトウェアによる使用に対して保存される。
正規化されたテーブルを識別する：
ステップ５は、単層ファイルの正規化である。単層ファイルの情報の残りの各必要な列に対して、アナリストはその主キー（その列の値を一意に識別する単層ファイルの情報の１または複数の列）を識別しなければならない。この行為は正規化されたリレーショナル・テーブルを単層ファイルの内部で識別する。何故ならば、異なる各主キーが異なる正規化されたテーブルを表現するからである。単層ファイルを別々の正規化されたテーブル構造に分解する必要はない（情報の各列が正しい主キーでマークされたら（関連していたら）、正規化されたテーブルは単層ファイルの内部で共存できる）。ＫｎＯＳでは、各主キーは１つの行のようなコンテキストに一意に関連する。
人工的なキーを識別する：
ステップ６は、人工的なキーの識別および削除である。テーブルは人工的なキー（ＡＫ）を有することが多く、人工的なキーは特有であるように創出された識別番号である。ＡＫは、長いＡＳＣＩＩ文字列であるか、または特異性問題を有するＰＫに取って代わることが多い。例えば、ユーザ名は個人テーブルの本当のＯＫであるが、名前は索引付け目的のためには長すぎ、２人の人間が同じ名前を有するかもしれない。もし便利な特有の（社会保障番号のような）数字ＰＫが存在したら、一般に単層ファイルはそれを保持する。もし主リレーションを番号付けするための便利な特有の数字が存在しなければ、単層ファイルはその目的のためのＡＫを保持する。もし、そのようなＡＫが単層ファイルに存在したら、それらは不必要であるとして識別されなければならず、同化されない。代わりに、正しいＰＫを、ＡＫが取って代わられたユーザ-アクセス可能な属性の１または複数の列として識別する。
いったん正しいＰＫが各ＡＫに対して識別されたら、単層ファイルの任意の特異性問題はアシミレータの前処理を用いて識別されなければならない。もし所定の正規化されたテーブルに対する正しいＰＫが同じ値であるが異なるＡＫをもつなら、重複するＰＫ値はアプリケーションのユーザにより解決されなければならない。同化のとき、値が特有になるように、スキームは決定されなければならない。解決スキームは、文字列（例えば、 John Paul Jones1, John Paul Jones2）の最後に整数を追加することに過ぎない。単層ファイルの正しいＰＫは、一貫性エラーを解決する前に特有の値に変換されなければならない。
複数主キー候補を選択する：
ステップ７は、複数候補が存在するときにＰＫを選択することである。単層ファイルの情報の必要な列は、そのＰＫに対して複数候補を有することが多い。これが起きるとき、アナリストは複数キーを同化する最善の方法を決定しなければならない。候補の１つは、ＫｎＯＳに対する主要なキーとして選ばれなければならない。全ての非キー列および残りの候補ＰＫは、同化の時の主要なキーに関連する。性能的理由のために、主要なＰＫを候補の中から選ぶとき、いくらかのケアが行われる。
例えば、ユーザ名および社会保障番号は、個人テーブルに対して競合する候補ＰＫである。命名された行のようなコンテキストが使用できてもできなくても、それは人間テーブルに対して同化される。テーブルのレコードにアクセスするためにユーザによって使用されることが多いものに基づいて、選択が行われるべきである。もしユーザが名前によって人情報にアクセスすることが最も多ければ、人名は主要なキーに対する正しいデータ・インスタンス値である。
いったん主要なキーが選択されたら、他のＰＫ候補は処置のために評価されなければならない。もし人名がＫｎＯＳの人間コンテキストに対する正しい属性なら、ＳＳＮはそれに密接に結び付けられるべきである。特に、もし著しい独立したアクセスをもつなら、ＳＳＮはそれ自体のＫｎＯＳコンテキストをもつ。しかし、人名が使用される全ての時に、ＳＳＮも要求されるようである。もしそうなら、それはＳＳＮを個人コンテキストのアイテム埋込要素として扱う性能に有利である。そのような決定は、同化の前に行われる。
一貫性エラー（テーブル・レベル一貫性）を解決する：
ステップ８は、テーブル・レベル一貫性の確立である。いったん、このマークアップが完了したら、単層ファイルは前処理されて参照一貫性エラーを識別しなければならない。単層ファイルのＰＫの所定の値が複数回だけＰＫが識別するデータの列に対する異なる値によって出現するときはいつも、参照一貫性エラーが出現する。換言すれば、もし所定のＰＫが列Ａ，ＢおよびＣを識別しＰＫの所定の値（インスタンス）が複数回だけ出現したら、Ａ，ＢおよびＣの値は各出現に対して同じでなければならない。もし同じでなければ、それは単層ファイルのテーブル・レベル一貫性エラーである。参照一貫性エラーは、２つのこと（識別されたＰＫ構造が正しくないこと、または不正な値が単層ファイルに存在すること）の中の１つである。いったん、ＰＫ構造エラーが訂正されたら、残りの不正な値はアプリケーションのユーザにより確認および解決されるべきである。
異なるユーザ人口は、単層ファイルの参照一貫性エラーを訂正するための確認アプローチを有する。あるものは、同化ソフトウェアが、多数の値（例えば、最初の１つが遭遇するという推測）の１つを任意に選ぶことを可能にする。他は、各参照エラーが解析によって解決されることを要求する。極端な場合、実際にはユーザが単層ファイルを再編成して、エラーを削除してもよい。参照一貫性エラーを解決する方法は、特定のインスタンスにおける精度に付随する重要性の程度に依存する。
ルックアップ（属性レベル一貫性）を標準化する：
ステップ９は、属性レベル一貫性の確立である。単層ファイルの多くの列は、ルックアップ値として識別される。これらの場合、ユーザは属性に対する値の範囲を指定して、属性レベル一貫性を新しいアプリケーションで確立する。単層ファイルにおける値の範囲は、ほぼ確実に、新しいルックアップ属性に対する値の所望する範囲に一致する。ＫｎＯＳ同化ソフトウェアは、（単層ファイル・ルックアップ値）対（標準化されたルックアップ値）のユーザ・マップを受け入れる機能を有する。最初に、アシミレータは、特定のルックアップ列の値の範囲を、その列に対してユーザにより選択された値の標準的な範囲と比較する。一致しない値は、一致する値にマップされる。このプロセスは、値の標準的なリストにおける変化を必要とする（即ち、範囲外の値のいくつかは、標準的なリストを編集したときにユーザが識別できなかった正しい値である）。いったん完了したら、ルックアップとしてラベルを付けられた任意の列を同化するときに、アシミレータ・ソフトウェアはこの相互参照マッピングを使用する。
これは、単層ファイルの処理を完了させる。今、それは、（命名された、命名されない、およびルックアップ）リレーションのためのリレーショナル標準化規則、およびＫｎＯＳへの同化に適したリレーショナル標準化規則に一致するような方法でマークされる。
拡張された構造（分類、およびコンテキスト）：
いくつかのアプリケーションでは、特定のＫｎＯＳコンテキストは、非常に大規模なＶＫセットを有する連想スコープにおいて非常に複雑なアイテムを有する。極めて大きなアイテムは、処理が更に困難である。何故ならば、それらのコンテキストが非常に広範だからである。もし、所定のコンテキストのコンテキストの処理が困難であれば、コンテキストのＶＫセットはコンテキスト（または、分類）に基づいて１または複数のタグ・セット・コンテキストにカプセル化できる。
ＫｎＯＳタグ・セットは、分類または分類法をデータベースに記録するために使用されるコンテキストの特別な型である。タグ・セット・コンテキストは、任意の独立したアイテムを保持しないことを除いて、標準的なコンテキストと同じ物理的構造をもつ。代わりに、タグ・セット・コンテキストのアイテムは効果的に複製されるか、またはアイテムを他のコンテキストで表現し、他のコンテキストはベースとして、またはタグ・セット・コンテキストのコンテキストに基づいて参照される。タグ・セット・コンテキスト・アイテムのＶＫセットは、何らかのサブセット、または対応する基になるコンテキスト・アイテム、または新しく創出されたコンテキストに適用可能な連想の別個の新しいセットのＶＫセットにより定義された連想の分類の何れかを記録する。換言すれば、タグ・セット・コンテキストは、連想の特定のコンテキストを、その中のアイテムに対するＶＫセットのサブセットとして記録する。
３つの型のタグ・セット・コンテキスト（標準的、マルチパス、および複合）が存在する。標準的なタグ・セット・コンテキストは、任意の標準的なコンテキストから創出できる。マルチパス・タグ・セット・コンテキストは、他の標準的なタグ・セット・コンテキストに基づく。複合タグ・セットは、１または複数のベース・コンテキストからのアイテムの選択された収集で構成される。以下の議論は、分類を向上させるために３つの型全てのタグ・セットの使用を記載し、コンテキストおよび性能を向上させる。
もし機能アプリケーションがそれを区別できたら、コンテキストは性能を向上させることだけをできることは明らかである。もし、分類法または分類がアクセスを行う機能アプリケーションに見えなければ、アプリケーションはコンテキストによって情報にアクセスできない。もし特定のコンテキストがアプリケーションに見えなければ、ＫｎＯＳはコンテキストからの改良の長所を取る基準をもたない。本当に、それは実際にはＫｎＯＳを遅くする。何故ならば、ものを探すための場所を更に創出するからである。
標準的なタグ・セット・コンテキスト：
標準的なタグ・セット・コンテキストは、任意の標準的なＫｎＯＳコンテキストに基づく。標準的な場合には、タグ・セット・コンテキストは基になるコンテキストと同じ数のアイテムをもち、対応するアイテムのデータ・インスタンスも同じである。この点（アイテムの数、データ・インスタンス、および構成）では、標準的なタグ・セット・コンテキストは、基になるコンテキストの正確な複製である。次に、コンテキストの中には、基になるコンテキストのＶＫセットに適用されるものもある。選択されたコンテキストに基づいて、一致する１または複数のＶＫセット要素は、ベース・コンテキスト・アイテムから合致する標準的なタグ・セット・コンテキスト・アイテムへ移動させられる。ソフトウェア・アプリケーションがその所定のコンテキストで動作するときはいつも、基になるコンテキストの代わりにタグ・セット・コンテキストにアクセスする。アプリケーションが所定のコンテキスト以外のコンテキストで動作するとき、基になるコンテキスト（または、他のタグ・セット・コンテキスト）を使用する。今、ベース・コンテキストは使用するには非常に単純である。何故ならば、所定のコンテキストが削除されたからである。タグ・セットは、データおよびビューモデル化の両方のために処理能力性能および一般的な編成を改良するＫｎＯＳ分類ツールである。
例えば、製造アプリケーションの部分コンテキストは極めて複雑なアイテム関係をもちそうであり、その結果、非常に大規模なＶＫセットをもつ。部分コンテナの連想の１つの有望な分類またはコンテキストは、「bill of materials」（ＢＯＭ）である。もし所望するなら、部分コンテキストでＶＫセットにより定義されたＢＯＭ連想は、ＢＯＭ標準的なタグ・セット・コンテキストにカプセル化できる。
「part」と呼ばれる標準的なコンテキストＫｎＯＳは、そのアイテム・データ・インスタンスとして、全部分の部分番号をもつ。ＢＯＭと呼ばれるタグ・セット・コンテキストは、部分コンテキストの各部分に対して１つのアイテムを保持するように確立され、各アイテムは同じアイテム・データ・インスタンスを有する。ＢＯＭ連想を表す部分コンテキストの「parent」および「child」ＶＫセットは部分コンテキストから除去され、ＢＯＭタグ・セット・コンテキストに配置される。他の全てのＶＫセットは、部分コンテキストに残される。これは全てのＢＯＭ分類の複雑さを部分コンテキストから除去する効果をもち、従って、部分コンテキストのアイテムのサイズを減少させ、ＢＯＭプロセッシングに関係しない部分を含む任意のアプリケーションに対する処理能力を改良する。アプリケーションがＢＯＭを必要とするときはいつも、部分コンテキストの代わりにＢＯＭコンテキストを呼び出す。
ＫｎＯＳは、タグ・セット・コンテキストのアイテムと基づいているコンテキストの間の１対１マッピングを自動的に維持する。この場合、アプリケーション・ソフトウェアはアイテムを追加されないか、またはアイテムをＫｎＯＳタグ・セット・コンテキストから削除しない。アイテムの追加および削除は、ＫｎＯＳ動作環境により処理される。アイテムは決して削除されないが、本来的に、それらは単にゼロであるＶＫセットをもつ。アイテムが基になるコンテキストに追加されるときはいつも、アイテムはタグ・セット・コンテキストに追加されるだけであり、対応するアイテムが基になるコンテキストから削除されるとき、アイテムはタグ・セット・コンテキストから削除されるだけである。例えば、もしアイテムが部分コンテキストから削除されたら、ＫｎＯＳもＢＯＭコンテキストの部分への全ての参照を削除し、ＢＯＭアイテム自体および任意のＶＫセットの両方がそれを参照する。ＶＫセットタグ・セット・コンテキストは、基になるコンテキストに「従属」する任意のＶＫセットである。
いくつの別個の連想コンテキストが標準的なコンテキストで識別されるかに、制限はない。標準的なＫｎＯＳコンテキストは、任意の数のタグ・セット・コンテキストに対する基準であり得る。例えば、部分−ベンダ連想も部分コンテキストから除去され、部分−ベンダ（ＰＴＶ）と呼ばれるタグ・セット・コンテキストに配置される。次に、誰が所定の部分を供給できるかに関するクェリがＰＴＶコンテキストを呼び出し、部分コンテキストを呼び出さない。この方法では、ベンダ・コンテキストが、部分コンテキストからカプセル化される。同じことがベンダ・コンテキストにも行われ、それにより部分連想をベンダ・コンテキストからベンダ−部分（ＶＴＰ）コンテキストへセグメント化する。
タグ・セット・コンテキストは、合致するタグ・セット（例えば、ＶＴＰ）コンテキストを他の方向に創出することなく、１方向（例えば、ＰＴＶ）に創出できる。タグ・セットは独立に注入でき、コンテキストまたは処理能力を向上させる。もしコンテキストまたは処理能力が向上しなければ、コンテキストによるＶＫセットによって定義された連想を分類するために、タグ・セットを注入する必要はない。
以下に記載されるマルチパスの除外により、１つのタグ・セット・コンテキストは他のタグ・セット・コンテキストには基づかない。上記の実施例では、ＰＴＶコンテキストでＶＫセットにより定義された連想は、本当のベンダ・コンテキストのアイテムだけを指し、ＶＴＰコンテキストの連想は、本当の部分コンテキストのアイテムだけを指す。ＰＴＶコンテキストのアイテムはＶＴＰコンテキストのアイテムを参照せず、逆も同様である。
そのような分類／コンテキストは、いつでも注入でき、カプセル化でき、またはＫｎＯＳから除去で生きる。従って、タグ・セット分類は、ＫｎＯＳにおける強力な調整ツールである。例えば、もしプロセスの任意の点で、ＢＯＭ連想が部分コンテキストを処理するには不必要に複雑に（または、遅すぎるように）していると決定されたら、ＢＯＭタグ・セット・コンテキストが創出できる。いったん創出されたら、（もし不必要であると決定されたら）ＢＯＭタグ・セット・コンテキストはいつでも削除できる。ＢＯＭコンテキストのＶＫセットは、部分コンテキストの対応するＶＫセットと単にマージされ、ＢＯＭコンテキストは削除される。
ＫｎＯＳタグ・セット技術は、コンテキストに基づいて機能する。更に多くのコンテキストがＫｎＯＳデータベースに存在するほど、処理は早くなる。例えば、汎用部分コンテキストからよりも専用のＢＯＭコンテキストからＢＯＭクェリを処理した方がはるかに早い。これは、ＢＯＭコンテキストが限定されたコンテキストを有するからである。必要なとき、さもなければ無視されたときに、それは呼び出される。部分コンテキストに反するオペレーションは、ＢＯＭ連想に負担されない。また、それは、ＫｎＯＳ競合がコンテキストの間に存在しないことを意味する。
ＫｎＯＳ「分類」スキームを、リレーショナル・モデル本来の２つの類似した処理能力問題（即ち、密度が低い行列、および行レベル競合）と混同しないことが重要である。
リレーションの属性が全てのタップルに当てはまらないときはいつも、密度が低い行列が出現する。この問題を調整するためのリレーショナル・アプローチは、異なる分類をリレーションの内部で識別し、「一般的」リレーションの密度が低い部分を１または複数の「カテゴリ」リレーションにセグメント化することである。換言すれば、データベースを正規形にする。
もし多すぎるユーザが同じテーブルおよび行を同時に使用しようとしたら、行レベル競合は問題になり得る。問題テーブルを別々の物理的テーブルへコンテキストに基づいてセグメント化することは、この型の競合を削除できることが多い。
ＫｎＯＳは、密度が低い行列（または、行レベル競合）の害を受けない。何故ならば、ＫｎＯＳは行列および行をもたないからである。コンテキスト、カテゴリ化、および分類は、ＫｎＯＳではリレーショナル・モデルと比較して非常に異なることである。
マルチパス型のタグ・セット・コンテキスト：
任意の企業データベース環境で最も困難な問題はクェリ反復であり、単一の要求が満たされる前に、何ダースもの独立した検索が要求される。このクェリ問題は、実際には本質的に連想であり、リレーショナルではない。ＡがＦに関連するかどうかを学習するために、Ｂに関連することを最初に学習しなければならず、次にＢがＣに関連することを学習し、ＥがＦに関連することを学習するまで同様である。Ａ−Ｂ−Ｃ−Ｄ−Ｅ−Ｆは、５つの別々の連想のマルチパス複合である。これら各連想は独立しており、何としてもアプリオリであるとは決定できない。ＡがＦに関連することを学習することは、５つの完全に独立したクェリが連続して（Ａ−Ｂ、Ｂ−Ｃ、Ｃ−Ｄ、Ｄ−ＥおよびＥ−Ｆ）行われることを要求する。もし潜在的スキームが複雑なネットワーク、または階層構造（即ち、マルチパス）ならば、この型のクェリは処理が殆ど不可能である。その様な場合、数百または数千の可能な経路に対するクェリは「fans-out」である。これらの型のクェリは、厳しい作業負荷問題をＤＢＭＳに示す。何故ならば、クェリの反復は並列に実施できないからである。
この反復問題の最善の実世界の実施例は、ＢＯＭプロセッシングである。字下げされたＢＯＭは部分の複雑な階層構造であり、１０以上の深さレベルであることが多い。マルチレベル爆発は、「left-to-right」マルチパス・クェリの階層的なバージョンである。それは、所定の部分の全ての「children」「grandchildren」等を検索する。マルチレベル爆縮 （「where used」）は「right-to-left」マルチパス・クェリの階層的なバージョン、またはネットワークのソースの方向を示すクェリであり、所定の部分アイテムの全ての「parent」「grandparent」等を検索する。部分アイテムＡが部分アイテムＢの製造に使用されるかどうか（または、その逆）を学習することは、何ダースもの反復を有する複合クェリであり得る。残念なことに、そのようなクェリはユーザに非常に人気がある傾向があり、従って、製造またはネットワーク環境において高い割合のコンピュータ作業負荷を一般に示す。
ＫｎＯＳでは、そのような全てのクェリは、マルチパス（または、ｍ−ｐ）型と呼ばれる特別な型のタグ・セット・コンテキストの使用により、単一の反復へ減少できる。上記の製造実施例では、ｍ−ｐ型タグ・セット・コンテキストは「マルチレベル」と呼ばれる。マルチレベル・タグ・セット・コンテキストのアイテムは、ＢＯＭコンテキストのアイテムの複製であり、部分コンテキストのアイテムの複製である。新しいｍ−ｐ型タグ・セット・コンテキストの各部分アイテムに対して、「parent」ＶＫセットはアイテムに対する「where used」マルチレベル爆縮からの全部分に対するベクトル・キーを含み、「child」ＶＫセットはアイテムに対するマルチレベル爆発からの全部分に対するベクトル・キーを含む。
このｍ−ｐ型タグ・セット・コンテキストは、単一の反復の中の任意のＢＯＭ型の質問に答える。例えば、「部分Ａは部分ＢとＢＯＭ関係を有するか？」。ＡおよびＢに対するＫｎＯＳ参照を学習した後、アイテムＡまたはＢの何れかをマルチレベル・コンテキストから検索すること、およびそのＶＫセットの１つの他のものに対するベクトル・キーを含むかをチェックすることにより、このクェリは直接的に答えられる。部分Ａおよび部分Ｂは任意の共通部分Ｃ，Ｄ，Ｅ ... に任意レベルで属するか？もしそうなら、どれに属するか？この表面上は単純なクェリは、リレーショナル・アプリケーションでの使用のためにプログラムされていないようであることを処理する、そのような食い違う複雑さを有する。ＫｎＯＳでは、クェリはマルチレベル・コンテキストの単一の反復（ＡおよびＢに対するアイテムをマルチレベル・コンテキストから検索し、一致のためにＶＫセットを比較する）で単純に答えられる。
もちろん、ＢＯＭ階層構造（例えば、ＢＯＭタグ・セット・コンテキスト）への各改訂は、全ての影響を受ける部分に対するマルチパス・タグ・セット・コンテキストのＶＫセットにより定義される連想を訂正するために、多数のマルチレベル爆縮および爆発を必要とする。ｍ−ｐ型のタグ・セット・コンテキストを更新することは容易ではないが、基になるコンテキスト、ＢＯＭの各変更は、ｍ−ｐ型コンテキストでのアトミック・オペレーションとして扱われ、作業負荷が許す限り処理する。各々の階層的な情報をロードまたは訂正したときに直ぐ２つのオペレーション（爆縮、および爆発）を行うことは、反復クェリが引き起こされる要求がある毎に２つのオペレーションを行うことよりも、ＤＢＭＳに対して更に効率的である。必要な連想をこの方法で分類することにより、ＫｎＯＳマルチパス型のタグ・セット・コンテキストは、製造アプリケーションの運用効率を２桁のオーダだけ向上させることが出来る。
ＫｎＯＳでは、タグ・セット・コンテキストはマルチパス型のタグ・セット・コンテキストとして設計でき、第２の分類タグ・セット・コンテキストに基づくことが出来る。ＫｎＯＳは爆発および爆縮を基になるタグ・セット・コンテキストで自動的に行い、マルチパス分類タグ・セット・コンテキストを得て、オペレーションの間に同期を維持する。上記実施例のマルチレベル・タグ・セット・コンテキストは、ＫｎＯＳで、ＫｎＯＳにｍ−ｐ型のコンテキストをＢＯＭタグ・セット・コンテキストに基づいて創出することを命令することにより確立される。他のアプリケーション・コードは、要求されない、ＫｎＯＳ環境は、コンテキストの創出を担当する。次に、変化が基になるＢＯＭコンテキストのＶＫセットで出現するたびに、ＫｎＯＳは自動的にマルチレベル・コンテキストのＶＫセットの同期を維持する。従って、クェリ反復は、ＫｎＯＳで、マルチパス・クェリに応答しなければならない任意の階層的な（または、ネットワーク）コンテキストに対するマルチパス型のタグ・セット・コンテキストを確立することだけによって削除される。ＫｎＯＳは、ｍ−ｐ型のタグ・セットの維持に関連する進行中の全オペレーションを、追加のアプリケーション・コード無しで処理する。マルチパス型のタグ・セット・コンテキストは、ＫｎＯＳを更にサポートする。
類似の分類アプローチは、リレーショナル・インプリメンテーションでは使用できない。何故ならば、リレーショナル・モデルは、連想分類構造を記憶して保持する便利でコンパクトな構造をもたないからである。上記ＫｎＯＳマルチレベル・コンテキスト実施例の所定の部分は、数千に分解する任意の数のＶＫセットをもち、部分毎に１行を有する単一のリレーショナル・テーブルの使用を削除する。従って、ＫｎＯＳマルチパス・ソリューションのリレーショナル・インプリメンテーションは２つの列を有するテーブルであり、テーブルの各行がマルチレベル・コンテキストのＶＫセットを模倣する。簡単に言うと、リレーショナル・ソリューションは、テーブルに収納された多量の「free vector」を使用する標準的な連想スキームである。並列ベクトル・プロセッサなしでは、このテーブルは処理が遅すぎて反復問題の大きな助けにならない。
「ビュー」のリレーショナル調整技術は、マルチパス問題を解決するために使用できない。何故ならば、リレーショナルＤＢＭＳは、十分な「ビュー」を１度に管理して問題を解決できないからである。単一のリレーショナル「ビュー」は、本質的に予想されたクェリの結果である。もしリレーショナル・インプリメンテーションが潜在的な各マルチパス・クェリ（それは、本質的に、どのＫｎＯＳが行うか）に対する１つのビューで確立されたら、リレーショナル・プロセッサはビュー保守オーバーヘッドを処理できない。要約すると、複雑なマルチパス構造（階層構造でもネットワークでも）にクェリを出すことにより起こる反復問題は、リレーショナル・モデル、または標準的な「free vector」連想モデルの内部で解決できない。
ＫｎＯＳは、劇的な向上を、ＤＢＭＳ効率において２つの技術により達成する。リレーショナル「結合」のＫｎＯＳ等価物は、処理が著しく単純であり、マルチパス・タグ・セット・コンテキストはクェリ反復を複雑なネットワークまたは階層上で削除するために使用できる。これら２つの問題は、従来のＤＢＭＳの殆どの性能問題の原因となる。
複合タグ・セット・コンテキスト：
タグ・セットの最終カテゴリは、「複合」と呼ばれる。（アプリケーションを定義することに対して広く有用な）複合タグ・セットは、多くの異なる方法で異なる目的のために形成できる。複合タグ・セットは、以下のものから成る。
ベース・コンテキストの完全なクローン（例えば、辞書コンテキストはクローンを作ることが出来る）。
ベース・コンテキストの完全なクローン−ＶＫセット。
コンテキストの任意の組合せから選択された、１組の完全にクローンを作られたアイテム。
コンテキストの任意の組合せから選択された、１組のクローンを作られたアイテム−ＶＫセット（例えば、ビュー・モデル）。
複合タグ・セット・コンテキストの内部のクローン（複製）は、タグ・セットの型に基づくＫｎＯＳ申し込みサービスにより自動的に維持される。以下の実施例は、 #4 複合タグ・セット・コンテキストの使用を示す。
アプリケーションの創出は、ユーザ・インターフェースが定義されることを必要とし、ユーザ・インターフェースはビューモデル化として参照されることが多い。ビューモデル化では、一般にデータ関係の特定のビューを構築するために必要な参照の収集は、１つより多いコンテキストからである。もしビューを構築して特定のユーザの必要性をサポートしたければ、そのビューの全表示要素はアイテムとして複合タグ・セットで表現できる。そのタグ・セットの表示要素の中の連想は、その特定のビューに対して固有であり、従って、そのビューのコンテキストに属するとして見ることが出来る。そのビューは、複合タグ・セットであり得る。そのアイテムは、ベース・アイテムが存在する任意のコンテキストから得ることが出来る。コンテキストのアイテム（例えば、「Web Display Elements」「Web Page」「Manufacturers」「Part」「Assemblies」および「Consumer Item」）は異なるコンテキストから得ることができ、複合タグ・セットに以下の方法で追加される。新しいウェブページが創出され、「Web Page」コンテキストに追加される。
新しいウェブページはコンテナから読み取られ、新しい複合タグ・セットを新しいウェブページと同じ名前で創出するために使用される。選択された表示要素は「Web Display Element」コンテキストから読み取られ、代表として、新しいウェブページ タグ・セットにコピーされる。この実施例について更に詳細には、「ＫｎＯＳレイヤ」を参照のこと。
データ・モデル化では、標準的なタグ・セットとして、複数のコンテキストを所定のアイテムに対して定義することが重要であることが多い。（数ダースが存在する）ＢＯＭおよび部分の実施例を（所定の部分を使用し保持する数百または数千の製造されたアイテムに）ＢＯＭ階層構造の任意レベルで拡張するために、別個の複合タグ・セットが各々および全ての製造されたアイテムに対して創出され、属しているときはいつでも、多くの異なる部分コンテキストからの部分が追加できる。任意の部分コンテキスト（例えば、特定の製造業者）からの任意の個別部分は、その階層構造に属しているときはいつでも、全ての製造されたアイテムのＢＯＭタグ・セット階層構造に追加できる。部分の中には（例えば、ワッシャまたはネジ）、殆ど何処でも全ての階層構造で出現するものもある。
コンテキストおよびスケール：
タグ・セット・コンテキストが１つの環境またはリポジトリ（Ｅ／Ｒ）で創出され、地理的に表示されたＫｎＯＳインプリメンテーションの中のコンテキストを向上させることが出来る、例えば、環境１ {1,0,0,0} および 環境２ {2,0,0,0} のユーザは、ＫｎＯＳを同じアプリケーション上で実施するときでさえ、どちらかといえば比較的独立したコンテキストを創出する。換言すれば、 {1,0,0,0} の僅かなＶＫセットが、環境２ {2,0,0,0} のアイテムに対するベクトル・キーを保持し、逆も同様である。これは、インプリメンテーションを実施しているユーザが、異なる環境のコンテキストに気付かず、大体は、それらに興味を持たないからである。同じ特徴が、リポジトリにも同様に当てはまる。環境１の内部で、リポジトリ１ {1,1,0,0} のユーザは、リポジトリ２ {1,2,0,0} とは異なるコンテキストを有する。
１つのＫｎＯＳ Ｅ／Ｒ は、コンテキストまたはアイテムに対するタグ・セット・コンテキストを、独立に、異なるＥ／Ｒで呼び出すことが出来る。異なる規則は、Ｅ／Ｒ境界全体で呼び出されるタグ・セット・コンテキストに当てはまる。
Ｅ／Ｒを横断するタグ・セットは、３つのレベル（「maintained」「non-maintained」または「localized」）の何れかで呼び出される。所定のリポジトリの内部の標準的なタグ・セット・コンテキストは、常に「maintained」される。もしタグ・セット・コンテキストが「maintained」なら、連想は基になるコンテキストに遅れないで（または、同期して）自動的に保持される。
所定のＥ／Ｒの内部では、タグ・セット・コンテキストは他のタグ・セット・コンテキストから創出できないが、異なるＥ／Ｒの間では、標準的なコンテキストおよびタグ・セット・コンテキストの両方が複製されて共有される。１つのＥ／Ｒからの分類または分類法のコピーは複製されて、他の内部に配置できる。これは、加入者のＥ／Ｒのコンピューティング・スーツにタグ・セット・コンテキストを局所的に調べる機能を与え、それにより局所的なＫｎＯＳサポート・ウィンドウを異なるＥ／Ｒの間に提供する。
もし「non-maintained」のタグ・セット・コンテキストが、１つのＥ／Ｒで異なるＥ／Ｒのコンテキストに基づいて創出されたら、Ｅ／Ｒ（例えば、 {2,0,0,0}/{2,3,0,0} ） を使用することは、「加入者」として発行者の（ホスト）コンテキストで確立される。そのような「non-maintained」タグ・セット・コンテキストはスナップショットであり、それが創出されたときだけ正確である。スナップショットを更新するために、加入者Ｅ／Ｒのアプリケーションは更新を要求するか、または更新要求を予定しなければならず、その時点で、加入者Ｅ／Ｒが新しいバージョンを発行者Ｅ／Ｒから要求する。加入者が新しいタグ・セット・コンテキスト・バージョンを発行者から受け取るとき、それはスナップショットに取って代わる。
もしタグ・セットが、Ｅ／Ｒ全体に「maintained」基準に基づいて創出されたら、ホスト・コンテキストが更新されるときはいつも、更新のコピーが加入者のリストに放送され、複製が同期され続けることを可能にする。これら発行者／加入者アクティビティは、ＫｎＯＳ環境から直接的に呼び出される。ＫｎＯＳは多次元参照に一般的な形式で構築されるので、Ｅ／Ｒの間の参照は、比較的単純明快なアクティビティである。Ｅ／Ｒの間のリンクまたはポータルは、オペレーションのルーチン部分として創出および削除できる。
もしタグ・セットが、環境全体に「localized」基準に基づいて創出されたら、最初に「local」ビューに表されるアイテムは、「localized」されて「local」タグ・セットで表現された他のアイテムを参照するＶＫセットだけをもつ。他の環境のアイテムを代表する「localized」を創出することは反復プロセスであり得るか、またはブロックとして行われる。「localizing」アイテムに対する主要な理由は、それらのソース環境連想からそれらアイテム別個に対する局所的なコンテキスト的連想を創出するためであり、全ての「localizations」を大域的に関連付けるためにベース・アイテムとの関係をまだ維持する。ＢＯＭおよび部分の実施例を更に拡張するために、消費財の製造は多数の設備を多数の国に有すると想定する。同じ消費アイテムの製造に使用される部品の中には異なるロケーションの異なる製造業者からのものがあり、従って異なる部品は「localized」タグ・セットに取って代わる。また、「localized」ＢＯＭタグ・セットはそれらの連想では完全に別個であるが、同じ部品アイテムを同じ階層的な位置にまだ有する。同じ部品が、全ての国の異なる配給元をもってもよい。その値付けは局所的な流通およびリードタイムであり、大口割引しきい値、および最低量は全て、各ロケーションに対して異なる。この場合、たとえ部分および階層がＥ／Ｒ全体で同じでも、「localized」タグ・セットは、異なるＶＫセットをＢＯＭの各部分に対して有する。
ＫｎＯＳレイヤ:
ＫｎＯＳは１００％階層化されており、完全に自己参照環境である。自己参照は、ＫｎＯＳアプリケーションの全構成要素が標準的なアイテム、コンテキスト、リポジトリ、および環境のデータベースに記憶されることを意味する。これは、全てのソフトウェア（呼び出し可能な機能、データベースＡＰＩ、ソースコード、等）を含む。Ｗｅｂフォームでさえ Java Server Pages または Active Server Pages として記憶されないが、他の任意のＫｎＯＳ特徴と丁度同じ様に、むしろコンテキスト、アイテム、およびＶＫセットを使用して定義される。ウェブページ上のボタン、および他のアクティブ特性は、ＫｎＯＳベクトル・キーを含み、ＵＲＬは含まない。Ｗｅｂフォームをブラウザに対してパッケージする前に、ＫｎＯＳソフトウェアはＫｎＯＳページ記述をＨＴＭＬに変換する。
これは、Ｗｅｂコンピューティングのための標準的な環境（例えば、 Sun Microsystems 社の Java（商標登録）standard （Java 2 Enterprise Edition （商標登録）または J2EE（商標登録）））と比較して、本当に無構造の環境である。 J2EE では、無数の Java classe が、ウェブ・アプリケーション・サーバ・スペースから呼び出されなければならない。ウェブ・アプリケーション・サーバは、高いトランザクション値に応答するために、垂直方向（大きなプロセッサ）および水平方向（多くのサーバ）の両方に堅固でなければならない。対照的に、ＫｎＯＳ構成要素は、性能が必要になれば、ネットワーク・コンピューティング・スタックの何処でも動作できる。例えば、アプリケーション自体、および関連するウェブページ構成は、クライアントのＰＣ、ウェブ・アプリケーション・サーバ、またはデータベース・サーバで動作できる。ＫｎＯＳコンピューティング構成要素の実行ロケーションは、アプリケーションの必要性、および提供されるハードウェアの量にだけ依存する。
インプリメンテーションにおける柔軟性、および最適化された性能に加えて、この設計は、ＫｎＯＳが、基本的なディレクトリ構造およびアプリケーション要素の配置を定義するために Hyper Text Transport Protocol （ＨＴＴＰ） Uniform Resource Locator （ＵＲＬ） に依存しないことを意味する。ＪＳＰ／ＡＳＰが使用されるとき、ファイル・システム中のそれらのロケーションは、非常に容易に無秩序になる。各開発者が何処にそれらを配置するかを選ぶことに依存して、異なるディレクトリに記憶された同じページ（または、コード）の多くのバージョンが存在する。アプリケーションに対する修正が行われるときはいつも、ＨＴＴＰおよびコードの派生インスタンスの「トラックを失い」、単純にそれらを「逃がす」ことは非常に容易であり、矛盾を導入し、追跡して訂正することが極めて困難な問題を起こす。ＫｎＯＳに関して、データベースでは、ページ定義、およびそれらの派生的バージョンが１カ所に存在し、アプリケーションが動作している間に変更できる。ＫｎＯＳウェブページの各構成部分が、アイテムおよびＶＫセットを使用してＫｎＯＳデータベースで別々に定義されるので、これは可能である。ページ構成要素アイテム（または、アイテム）を変更することは、１または複数のアイテムを使用する全ウェブページを自動的に変更する。
企業スケーラビリティ：
ＫｎＯＳ・アーキテクチャは、企業スケーラビリティに対する性能エンベロープを定義する。ファイアウォールのための専用のノード。インバウンドＨＴＴＰディスパッチャ、セッション・マネージャ、辞書マネージャ、およびデータ・サーバが存在しうる。リレーショナル・コンピューティング・モデルとは異なり、ＫｎＯＳは、中間クェリ結果が各ユーザ・セッションでの継続性のためにセーブされることを要求しない。その結果、ＨＴＴＰディスパッチは単純（稼働率／作業負荷駆動）であり、プーリング専用のプロセッサの数であり、フィルタリングおよびＸＭＬパッケージングは、並列ユーザ・セッションの増加を処理する必要に応じて拡張できる。ＫｎＯＳデータベース・オペレーションは非常に効率的で予測可能なので、並列ユーザの追加の数にサービスするために追加のコンピューティング能力が一般に要求されない。しかし、更に多数の並列セッションにサービスするため、またはテラバイトの範囲を測定するディスク・ファームにサービスするための何れかのために、データベース・プロセッサの数は、緩やかに結合されたクラスタ・アーキテクチャ全体に拡張できる。
企業アーキテクチャ：
図２１「ＫｎＯＳスケーラビリティ」は、如何にして一般的な最高仕様のサイトが、最悪の仮定の元で形成されるかを図示する。高速バスにより相互接続された緩やかに結合されたプロセッシング・ノードの範囲である。ＨＴＴＰ要求が、ファイアウォール・ノードで受信される。もしクリアされたら、ＨＴＴＰ要求はＨＴＴＰディスパッチ専用のノードに転送される。サービスを提供されなければならない並列ユーザ人口のサイズ、およびプーリング、フィルタリング、およびＸＭＬパッケージングで特定のアプリケーションによりもたらされる困難の程度に依存して、「ｋ」ウェブ・アプリケーション・サーバが存在し、各々は多数のプロセッサを有する。この実施例は、２つのリポジトリが辞書専用であり、 {1,1,2,0} がシステムに維持される {1,1,1,0} の複製（タグ・セット）であることを示す。最後に、データベース・サービス専用の３つの（「ｎ」）リポジトリが存在する。各データベース・サーバは１００ＧＢ以上を管理するか、または非冗長データを管理する。通常は、アプリケーションは、データベース・サーバのための論理分割スキームをサポートし、ウェブ・アプリケーション・サーバは、何のデータがどのサーバに配置されているかを知ることが出来る。この実施例は、データを論理的に分割する機能を仮定しない。いつ受信したか、またはアクセス・プロファイルに関連する作業負荷に基づいて、アイテムは、３つの（「ｎ」）データ・サーバ・リポジトリ全体に分散する。
図２１に示される典型的なシナリオは、このようである。
ステップ #1 - ＨＴＴＰ要求がインターネットによって受信され、ファイアウォールにおいて処理される。
ステップ #2 - もし正しければ、ＨＴＴＰ要求は単一のディスパッチャ・ノードに転送される。
ステップ #3 - ディスパッチャは、ＨＴＴＰメッセージに埋め込まれた／暗号化されたログオン、または認証セッション証明の何れかを処理する。もし本物なら、ディスパッチャが、機能しているウェブ・アプリケーション・サーバの中で作業負荷に基づいて要求を分ける。この場合、ＨＴＴＰ要求は、サービスのためにウェブ・アプリケーション・サーバ #1 へ送られる。
ステップ #4 - ウェブ・アプリケーション・サーバ #1 が、セッション証明およびＨＴＴＰメッセージを解析／復号化することによりセッションを確立する。
ステップ #5 - もし有効なら、ＨＴＴＰメッセージは、１または複数の情報を要求する。ウェブ・アプリケーション・サーバ #1 は、ＡＳＣＩＩサーチ要求サービスのための辞書サーバ {1,2,0,0} に割り当てられる。ウェブ・アプリケーション・サーバ #1 は、辞書サーバ {1,1,2,0} に１組のＡＳＣＩＩ値をトランザクションから課し、ＡＳＣＩＩ変換を要求する。サーバ {1,1,2,0} は要求されたＡＳＣＩＩ変換を行い、要求されたアイテム・ベクトル・キーをウェブ・アプリケーション・サーバ #1 上のセッションへ戻す。
ステップ #6 - ウェブ・アプリケーション・サーバ #1 は要求されたアイテム・ベクトル・キーを受信し、１組の指示されて、参照されたフェッチを、データ・サーバへ、各アイテム・ベクトル・キーのリポジトリＩＤ番号に基づいて発行する。換言すれば、アイテム・ベクトル・キーは、どのサーバが要求される各アイテムを含むかを識別する。リポジトリ {1,1,3,0}, {1,1,4,0}, および {1,1,n,0} に対するデータ・サーバは、参照されたフェッチを、要求されたアイテムに対して、図２１に示された方法で行う。データ・サーバは、要求されたアイテムを、要求しているセッション・マネージャ、ウェブ・アプリケーション・サーバ #1 へ戻す。
ステップ #7 - セッション・マネージャは要求されたアイテムを受信し、指示されたプーリング／フィルタリング・オペレーションを行い、追加データを検索する必要に応じてステップ #6 を繰り返す。
ステップ #8 - ウェブ・アプリケーション・サーバは、アプリケーション・コードに含まれる命令に従い、データ・サーバから要求される追加の任意の答えの値を検索する。
ステップ #9 - ウェブ・アプリケーション・サーバはウェブページをレンダーし、ＸＭＬをパッケージし、セッション証明を暗号化し、ＨＴＴＰ応答を構成し、それをＨＴＴＰディスパッチャに戻す。現時点で、セッションは完了し、ウェブ・アプリケーション・サーバから消される。リクエスタに戻すために、ＨＴＴＰディスパッチャは、ＨＴＴＰ応答を、インターネットへ、ファイアウォールを通してディスパッチする。
ＫｎＯＳ・アーキテクチャは１００％並列なので、リレーショナル選択オペレーション（ステップ #6）の等価物は、リレーショナル結合に対する等価物から分離できる。（ＲＤＢＭＳの中心的ボトルネックである）結合オペレーション（プーリング／フィルタリング）のＫｎＯＳ等価物は、コンピューティング・スタック（データベース・プロセッサ、ウェブ・アプリケーション・サーバ、またはデスクトップ）の任意のレイヤで実行できる。これは、プーリング／フィルタリング・オペレーション（結合のＫｎＯＳ等価物）を呼び出す前に、選択で得られたアイテムを指定された処理ロケーションへ単純に渡すことにより行われる。図２１の場合、プーリング／フィルタリング・オペレーションは、ウェブ・アプリケーション・サーバに委ねられてきた。
各アイテムはプリミティブ・レベルの細分性で完全にカプセル化されるので、データ・ファームは、任意の数のデータ・サーバ全体に、競合を増加させることなく広がることが出来る。また、ディスク配置の連続の必要性がないので、アイテムは、データ・サーバ全体に、作業負荷を平衡させる要求プロファイルに基づいて配置できる。辞書サーバ {1,1,2,0} は、ＫｎＯＳ申し込みサービスにより維持された複製を有する {1,1,1,0} の複製されたタグ・セットである。作業負荷を平衡させる任意の数の辞書サーバが存在する。
これは、プロセッシング・ノードの緩やかに結合されたクラスタである。ノードの間の共有メモリに対する要求は存在しない。連携処理に対する全ての要求は、単純な参照されたフェッチに厳密に基づく。従って、高速バス上の全トラフィックは、ＨＴＴＰまたは参照されたフェッチの何れかである。全データは、データ・サーバに収納された１または複数のアイテムに埋め込まれる（補助データ・リポジトリは存在しない）。全ての重要なサーバ（例えば、ウェブ・アプリケーション・サーバ、辞書サーバ、およびデータ・サーバ）は、作業負荷を満たす必要に応じて拡張できる。容易に拡張できない唯一の競合するリソースは、メイン・バスである。
ＫｎＯＳ・アーキテクチャは、単一の環境の内部で企業コンピューティングの必要を満たす並列処理技術を使用してスケールでき、しかもスケーラビリティはインストレーションの寿命全体を通して当てはまる。複数のＫｎＯＳ環境が、類似の連動基準で機能できる。
連想オペレーションのスケーラビリティ：
ＫｎＯＳデータベース・プロセッサは、本質的に１００％の稼働率をプロセッサから得ることが出来る。何故ならば、ＫｎＯＳデータベース・オペレーションは、カプセル化された整数演算だけを使用するからである。例えば、プーリングと呼ばれる基本的な連想オペレーションを考える。基本的なプーリング・オペレーションは、２つの異なるアイテムに対するＶＫセットの２つの完全にカプセル化された分類を取り、ベクトル・キーの２つの 配列の間の論理積（一般に、ブール論理積演算）を決定する。例えば、ＶＫセットの「child」分類をアイテムＡから選択し、ＶＫセットの「parent」分類をアイテムＢから選択する。基本的なプーリング・オペレーションを２つの配列で行うことは、Ａの「children」またはＢの「parents」を、オリエンテーションに依存して決定する。従って、オペレーションは、所定のコンテキスト（この場合には コンテキスト = 「parent/child」）に対する２つのアイテムの間の関連の完全な範囲を識別し、これが連想ＤＢＭＳのコア・オペレーションである理由である。
各アイテムに対して、ＫｎＯＳの好ましい実施例は、ＶＫセットを正しい順序で各ベクトル・キー次元の内部に維持する。例えば、「parent」の分類の内部で、ベクトル・キー {0,3,2,4} は {0,3,1,4} の後に来るが、記憶媒体では {0,3,2,7} の前に来る。基本的なプーリング・オペレーションは（この方法で配置された）ベクトル・キーの２つの配列を比較し、２つのアイテムのＶＫセットの論理積を決定する。以下の議論は、単一のアイテム上のＶＫセットの単一の分類が特有のエントリから成ることを仮定する。単一のアイテムに対するＶＫセットの単一の分類が所定のベクトル・キーの２以上のコピーを有することが可能であるが、それは以下のオペレーションの議論に対しては取るに足りない変化である。
２つの参照分類がプールされ、出来るだけ少ない数のベクトル・キーを有する配列が「ドライバ」配列と呼ばれ、ベクトル・キーを更に有する配列が「ターゲット」配列と呼ばれる。ドライバ配列の一番下の（例えば、{0,0,1,0} ）ベクトル・キー・エントリで始めると、プーリング・オペレーションが、合致するベクトル・キーを、ターゲット配列の中で、標準的な２分木検索によって探す。もし、ベクトル・キーの合致が２分木検索の結果見付かれば、ベクトル・キーのコピーがソリューション・セットに挿入され、ＶＫセットの論理積を表現し、ターゲット配列の次のエントリのロケーションが、サーチの次の反復での使用のために特記される。もしターゲットの合致が見付からなければ、現在のドライバ・ベクトル・キーより少し大きいターゲット配列のエントリのロケーションが、次の反復での使用のために特記される。
特記されたロケーションを先導するターゲット配列の部分は、所定のプーリング・オペレーションでの継続的な２分木検索に対して無視される。何故ならば、ターゲット配列のその部分の全ベクトル・キー・エントリが、ドライバ配列から処理されている現在のエントリより小さいからである。これは、２分木検索を最適化する。プーリング・オペレーションは、この方法で、ドライバ配列の次の各エントリを用いて、ドライバ配列の全ベクトル・キーがターゲット配列に反してチェックされるまで継続する。この最適化された２分木検索は、実際には、ベクトル・キーのＶＫセット配列は一般に長い文字列のベクトル・キーを所定のコンテキストに対して保持しているという事実により、更に最適化される。従って、２分木検索は、「load and compare」オペレーションの「compare」部分を、ベクトル・キーのアイテム構成要素でのみ実行でき、 {E,R,C,I} のＥ，ＲおよびＣ要素を、アイテム一致が見付かったときだけチェックする。
上記の方法で最適化され、各々で順序付けられたベクトル・キーを有する２つのＶＫセット配列は、約１０個の最適化された２分木検索／「ドライバ」エントリ（最初のドライバ・エントリに対しては更に多くの検索、後のドライバ・エントリに対しては更に少ない検索）を平均でき、「ターゲット」配列の一致を検査する。各２分木検索動作は、プロセッサに対する「load and compare」オペレーションである。もし、プロセッサのパイプラインが最適化されたら、各「load and compare」オペレーションは単一のクロック・サイクルで完了する。
これらの優れた実施番号でさえ、複数の未解決のコンテキストを含んでいそうな多くのベクトル・キーを有する単一のＶＫセット分類を用いてそのアイテムを識別することにより、著しく「調整」できる。最適性能のために、これら混合されたコンテキストの各々は、それらを分類し、次にそれらを独立したタグ・セット・アイテムへセグメント化することにより解決されるべきである。もし、大きなＶＫセットが、４つの独立したタグ・セットにコンテキストに基づいてカプセル化されたら、プーリング・オペレーションを行うために要求される時間は、プロセッサ・リソースの４分の１だけを消費する。これは、全ＫｎＯＳデータベース・トランザクションが、コンテキスト・センシティブだからである。混乱したコンテキストをデータベース定義から削除することにより、ＫｎＯＳは著しく小さい処理作業負荷経験して同じ結果を達成する。
例えば、ジョブ・チャージ番号、労働カテゴリ、人間、週により労働計画を行うアプリケーションを考える。従業員10,000人に対する主要な企業インプリメンテーションでは、このＫｎＯＳデータベースは「４０」時間に関連する百万のベクトル・キーを含む。もし「４０」アイテムがこれらのベクトル・キーを単一の分類スキームにもつなら、それは性能問題をもたらす。もしそうなら、「人間」コンテキストは「４０」アイテムのＶＫセットに対して確立され、各人間は個人の「４０」ベクトル・キーから成る自身のタグ・セットを有する。次に、10,000個の個人専用にされた各タグ・セットは、百万の代わりに平均して「４０」アイテムを参照する100個のベクトル・キーだけを有する。人間が既知であるデータベース・トランザクションに対して、これは10,000/1の因子だけトランザクション処理をスピードアップする。アプリケーションの実際の作業負荷プロファイルを調べることにより、ＶＫセットはタグ・セットへデータベースの性能を向上させる「コンテキスト」によりカプセル化でき、それによりオペレーションの効率を実質的に向上させる。
６つの概念に基づくＫｎＯＳの非常に高いスケーラビリティ・プロファイル
ＫｎＯＳは、非常に広範な配布／並列化を、トランザクションの間の競合の著しい増加なしにサポートする。何故ならば、その完全にカプセル化する機能は、ａ）細分性の非常に低いレベルにおけるデータ、およびｂ）中心的連想オペレーションの両方だからである。
コンピューティング・リソースが利用可能な所であれば何処でも、同じ機能を実施するプロセッサ全体に、ＫｎＯＳ連想オペレーションは、水平方向に分配および並列化でき、垂直方向にアーキテクチャのスタックを上下させる。（ＤＢＭＳ作業負荷の９９％を表す）中心的ベクトル・キー・プーリング・オペレーションは、辞書サーバ、データベース・サーバ、ウェブ・アプリケーション・サーバ、またはエンドユーザのＰＣで実施できる。
ＫｎＯＳ連想オペレーションは単純な整数演算であり、プロセッサの本質的に１００％の稼働率を達成するようにステージ化できパイプライン化できる。
（エンドユーザ・トランザクション毎に要求されるプロセッサ・タイムで測定される）オペレーションのＫｎＯＳの効率は、インプリメンテーションの後に訂正され、ボトルネックを削除し、各ボトルネックに対する正しい「コンテキスト」を識別し、ＶＫセットを専用のタグ・セットへコンテキストによってセグメント化する。全ＫｎＯＳボトルネックは、非常に広範な（または、混乱した）コンテキストを用いてＶＫセットのクラスタに関連付けられる。
ＫｎＯＳは、ユーザ・セッションにおける継続性のために中間結果をセーブする必要はない。何故ならば、それは各時間にプロセスを繰り返すのに十分効率的だからである。オープン・セッションを、各ユーザの中間結果を有する任意のシステム・サーバ上で維持する必要がないと仮定すると、ＨＴＴＰディスパッチはトランザクションを最小の作業負荷を有するサーバに向けることが出来る。
最後に、各ＫｎＯＳコンテキストは本質的に第２のキー・インデックスなので、ＫｎＯＳインプリメンテーションの作業負荷プロファイルは実施されているトランザクションの型または複雑さに依存しない。
ＫｎＯＳは、高度にスケーラブルである。何故ならば、データでもオペレーションでも、それは、システム・リソースに対して非常に限定された競合により並列化できる、比較的小さな完全にカプセル化された構成要素へ分解できるからである。また、ＫｎＯＳ設計なので、トランザクションの異なる各型が、ほぼ同じ作業負荷プロファイルをプロセッサに示す。タグ・セットの使用によってデータベースのコンテキスト（分類スキーム）を改良することにより、ＫｎＯＳは性能調整可能であり、各トランザクションだけが、関連するコンテキストの内部でデータを調べなければならない。
ファジー連想:
コンピューティングの発展に重要なトピックは、ファジー論理である。ファジー論理の内部で構築された容易化アプリケーションに対して、ＫｎＯＳより適切な処理モデルはない。
コンピュータについての多くの非難が出現する。何故ならば、一般にコンピュータは、正確な論理を使用するからである。コンピュータが「Paco Verde」および「Paul Green」を比較するとき、一致を検出しない。コンピュータが「1028 Morningside Way」を「1028 Mornignside Way」と比較するとき、一致を検出しない。コンピュータが「Paco Verde」が「1028 Morningside Way」に住んでおり、「Paul Green」が「1028 Mornignside Way」に住んでいることを指示されたとき、コンピュータは一致するパターンをまだ検出しない。殆どの人間は、これらの一致を直ぐに見付ける。データ・インスタンスは、スペイン語および英語において、各々同じであり、アドレスが互いに間違って綴られている。これらは、ファジー次元で一致する。換言すれば、言語の違いおよび綴り間違いを無視することにより、コンピュータは「Paco Verde」および「Paul Green」が非常に強い関連をもつことを決定できる。それらは同じデータ・インスタンス値を言語次元にもち、綴り間違い次元の同じアドレスに居住する。ファジー論理からの妥当な結論は、「Paco Verde」および「Paul Green」がエイリアスだということである。
ＫｎＯＳはセルラ・モデルでありＲＤＢＭＳではないので、ＫｎＯＳは、特定のアプリケーションにより定義される出来るだけ多くのファジー次元を収容、記憶、および検索できる。例えば、アプリケーションは、綴り間違いに対する１つのファジー次元、および言語等価物に対して他のファジー次元を確立する。次に、アプリケーションは、ファジー連想のためのＫｎＯＳに、（ parent/child のような）正確な連想と丁度同じようにＶＫセットを挿入できる。アプリケーションがファジー連想を識別するとき、それらを記録できる。これらのファジーＶＫセットは、追加のＶＫセット分類としてアイテムの内部に、または別々のタグ・セットとしてコンテキストにより含まれる。この方法では、ＫｎＯＳは次元を分離できる。正確なコンテキストでクウェリを出されるとき、ＫｎＯＳは「Paco Verde」と「Paul Green」の間に一致を見出さない。ファジー言語次元でクウェリを出されるとき、一致を見出す。
従来技術のリレーショナル・データ・モデルの図表を示す。 如何にしてリレーショナル・モデルの主リレーションがＫｎＯＳに同化されるかを示す。 如何にしてリレーショナル・モデルの連想リレーションがＫｎＯＳに同化されるかを示す。 如何にして図１からの主および連想リレーションの行および列がＫｎＯＳコンテキストに同化されるかを示す。 図１のリレーショナル・モデル実施例からの全関係の同化を示す。 意味論的バイナリ・データ・モデルとして図示される図１からのリレーショナル・モデル実施例を示す。 如何にして意味論的バイナリ・データ・モデルの単一セグメントがＫｎＯＳコンテキストに同化されるかを示す。 意味論的バイナリ・データ・モデルおよびＫｎＯＳモデルの両方として図１に示されるリレーショナル・モデルを示す。 なぜＫｎＯＳコンテキスト構造が独立したアプリケーションなのかを示す。 ＫｎＯＳオペレーションを図１に図示される等価物リレーショナル・オペレーションと比較している。 ＫｎＯＳプーリング・オペレーションの実施例を示す。 ４次元参照モデルを示す。 ＫｎＯＳアイテムの構造を示す図表を示す。 ＫｎＯＳの対称な参照を示す。 如何にしてＫｎＯＳ・ＡＳＣＩＩがＡＳＣＩＩ値を等価物ＫｎＯＳベクトル・キーへ変換するかを示すプロセス・モデルを示す。 如何にしてＫｎＯＳ・ＡＳＣＩＩがＡＳＣＩＩ値を等価物ＫｎＯＳベクトル・キーへ変換するかを示すプロセス・モデルを示す。 アイテムのベクトル・キーに基づいてアイテムをフェッチするための６つのステップを示す図表を示す。 リポジトリとしての基本的なデータ構造の図表を示す。 コンテキストおよびアイテムとしての基本的なデータ構造の図表を示す。 ＫｎＯＳアイテムを物理的媒体上で更新するための方法の実施例を示す。 ＫｎＯＳアイテムを物理的媒体上で更新するための方法の他の実施例を示す。 ＫｎＯＳスケーラビリティを実演するためのＫｎＯＳ・アーキテクチャを示す。 環境の間の相互参照を示す ＡＳＣＩＩおよびＫｎＯＳ値表現の間の比較を示す。 リレーショナル意味論的バイナリおよびＫｎＯＳデータ・モデルの間の対称性（または、その欠如）を示す。 ＫｎＯＳアイテムの構造的対称性を示す。 ＫｎＯＳコンテキストの構造的対称性を示す。 ＫｎＯＳ設計の対称性を示す。 ＫｎＯＳを組み込んだ一般的なコンピューティング環境のブロック図を示す。 ファームウェアを使用する実施例を示す。 従来技術を示す。

Claims (96)

  1. コンピューティング環境のデータ管理システムであって、
    ａ．データ・インスタンス中心アーキテクチャを含み、
    ｂ．各データ・インスタンスは、共通の基本的なデータ構造でカプセル化され、および
    ｃ．前記共通の基本的なデータ構造も、関連する別々にカプセル化されたデータ・インスタンスへの参照をカプセル化することを特徴とする、データ管理システム。
  2. 前記データ・インスタンス中心アーキテクチャ、および前記共通の基本的なデータ構造が構造的対称性を有することを特徴とする、請求項１に記載のデータ管理システム。
  3. 第１のデータ・インスタンスが、関連するデータ・インスタンスへの参照を用いてカプセル化され、前記各関連するデータ・インスタンスが、前記第１のカプセル化されたデータ・インスタンスへの参照を用いて別々にカプセル化されることを特徴とする、請求項１に記載のデータ管理システム。
  4. 前記データ・インスタンス中心アーキテクチャ、前記基本的なデータ構造、前記カプセル化されたデータ・インスタンス、および参照が構造的対称性および関係対称性を有することを特徴とする、請求項３に記載のデータ管理システム。
  5. 第１のデータ・インスタンスは、関連するデータ・インスタンスへの参照を用いてカプセル化され、前記各関連するデータ・インスタンスは、前記第１のカプセル化されたデータ・インスタンスへの参照を用いて別々にカプセル化され、
    各々の前記カプセル化された参照は、各々の前記関連するカプセル化されたデータ・インスタンスを一意に識別する論理インデックスであり、各々の前記関連するカプセル化されたデータ・インスタンスのロケーションも符号化し、および
    前記論理インデックスは「ｍ」次元であり、１次元毎に「ｎ」ビットを有することを特徴とする、請求項１に記載のデータ管理システム。
  6. 前記データ・インスタンス中心アーキテクチャ、前記基本的なデータ構造、前記カプセル化されたデータ・インスタンス、および参照が、構造、関係、値、および収納対称性を有することを特徴とする、請求項５に記載のデータ管理システム。
  7. 前記カプセル化された参照が、少なくとも１つの次元にあり、および
    各々の前記少なくとも１つの次元が、１つのタイプの関連に対応することを特徴とする、請求項１に記載のデータ管理システム。
  8. 各々の前記少なくとも１つの次元が、複数の前記カプセル化された参照を有することを特徴とする、請求項７に記載のデータ管理システム。
  9. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項１に記載のデータ管理システム。
  10. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項２に記載のデータ管理システム。
  11. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項３に記載のデータ管理システム。
  12. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項４に記載のデータ管理システム。
  13. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項５に記載のデータ管理システム。
  14. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項６に記載のデータ管理システム。
  15. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項７に記載のデータ管理システム。
  16. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項８に記載のデータ管理システム。
  17. 前記カプセル化された参照の少なくとも１つが、他のコンピューティング環境のカプセル化されたデータ・インスタンスへの参照であることを特徴とする、請求項１に記載のデータ管理システム。
  18. 前記カプセル化されたデータ・インスタンスの少なくとも１つの前記カプセル化された参照が一意であり、前記カプセル化されたデータ・インスタンスの少なくとも２つの前記カプセル化された参照が一般に同一であることを特徴とする、請求項１に記載のデータ管理システム。
  19. 前記データ・インスタンス中心アーキテクチャが複数の既存のカプセル化されたデータ・インスタンスを含み、前記複数の既存のカプセル化されたデータ・インスタンスが関連を確立し、少なくとも１つの新しいカプセル化されたデータ・インスタンスが、前記既存のカプセル化されたデータ・インスタンスの少なくとも１つと関連することを特徴とする、請求項１に記載のデータ管理システム。
  20. 前記データ・インスタンス中心アーキテクチャが複数の既存のカプセル化されたデータ・インスタンスを含み、前記カプセル化されたデータ・インスタンスが関連を確立し、任意の前記既存のカプセル化されたデータ・インスタンスが、他の既存の関連するカプセル化されたデータ・インスタンスから削除されて関連を解消できることを特徴とする、請求項１に記載のデータ管理システム。
  21. 前記データ・インスタンス中心アーキテクチャが複数の既存のカプセル化されたデータ・インスタンスを含み、前記カプセル化されたデータ・インスタンスは関連を確立し、少なくとも２つの既存のカプセル化されたデータ・インスタンスの間の新しい関連が追加できることを特徴とする、請求項１に記載のデータ管理システム。
  22. 前記データ・インスタンス中心アーキテクチャが複数の既存のカプセル化されたデータ・インスタンスを含み、前記カプセル化されたデータ・インスタンスが関連を確立し、前記既存のカプセル化されたデータ・インスタンスの間の前記既存の関連の幾つかが削除できることを特徴とする、請求項１に記載のデータ管理システム。
  23. ａ．選択基準を表現する前記不明のカプセル化されたデータ・インスタンスにアクセスすることにより、不明のカプセル化されたデータ・インスタンスの前記選択基準から特定の不明のカプセル化されたデータ・インスタンスを見出し、
    ｂ．前記選択基準を表現する前記不明のカプセル化されたデータ・インスタンスを用いてカプセル化された参照にアクセスし、
    ｃ．前記特定の不明のカプセル化されたデータ・インスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および
    ｄ．前記特定の不明のカプセル化されたデータ・インスタンスを検索することを更に含むことを特徴とする、請求項１に記載のデータ管理システム。
  24. ａ．前記カプセル化された参照が、複数次元の論理インデックスとして実施され、
    ｂ．前記各次元が、１つのタイプの関連に対応し、および
    ｃ．前記アクセスが、前記選択基準で指定された前記次元からの前記カプセル化された参照へのアクセスを更に含むことを特徴とする、請求項２３に記載の方法。
  25. 前記カプセル化された参照が「ｍ」次元論理インデックスであり、前記関連するカプセル化されたデータ・インスタンスのロケーションを各「ｍ」次元論理インデックスが一意に識別して符号化し、および
    前記「ｍ」次元論理インデックスの少なくとも１つでのブール演算により前記カプセル化された参照をフィルタすることを更に含むことを特徴とする、請求項２３に記載の方法。
  26. 前記カプセル化された参照が「ｍ」次元論理インデックスであり、前記関連するカプセル化されたデータ・インスタンスのロケーションを各「ｍ」次元論理インデックスが一意に識別して符号化し、および
    前記「ｍ」次元論理インデックスの少なくとも１つでのブール演算により前記カプセル化された参照をフィルタすることを更に含むことを特徴とする、請求項２４に記載の方法。
  27. 前記ブール演算が、
    単一の演算における前記比較の結果からの少なくとも１つのカプセル化された参照の直接実行をもたらす基本的な算術演算子を更に含むことを特徴とする、請求項２３に記載の方法。
  28. 前記ブール演算が、
    単一の演算における前記比較の結果からの少なくとも１つのカプセル化された参照の直接実行をもたらす基本的な算術演算子を更に含むことを特徴とする、請求項２４に記載の方法。
  29. 前記ブール演算が、
    単一の演算における前記比較の結果からの少なくとも１つのカプセル化された参照の直接実行をもたらす基本的な算術演算子を更に含むことを特徴とする、請求項２５に記載の方法。
  30. 前記ブール演算が、
    単一の演算における前記比較の結果からの少なくとも１つのカプセル化された参照の直接実行をもたらす基本的な算術演算子を更に含むことを特徴とする、請求項２６に記載の方法。
  31. 前記カプセル化されたデータ・インスタンスが、ユーザ・インターフェースの属性を有することを特徴とする、請求項１に記載のデータ管理システム。
  32. ユーザ・インターフェースの前記属性が、ユーザ・ビュー、表示要素、およびデータ・アクセス方法のグループから選択されることを特徴とする、請求項３１に記載のデータ管理システム。
  33. 前記システムを検索し、異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、所望する結果を導出するために使用されることを特徴とする、請求項１に記載のデータ管理システム。
  34. 異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が共通性、類似性、および差異の少なくとも１つに対して比較され、前記所望する結果に対応する参照のセットを導出することを特徴とする、請求項３３に記載のデータ管理システム。
  35. 異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が順番に値に基づいて記憶され、共通性、類似性、および差異の少なくとも１つに対して比較され、前記所望する結果に対応する参照のセットを導出することを特徴とする、請求項３４に記載のデータ管理システム。
  36. 第１のデータ・インスタンスは、関連するデータ・インスタンスへの参照を用いてカプセル化され、前記各関連するデータ・インスタンスは、前記第１のカプセル化されたデータ・インスタンスへの参照を用いて別々にカプセル化され、
    各々の前記カプセル化された参照は、各々の前記関連するカプセル化されたデータ・インスタンスを一意に識別する論理インデックスであり、各々の前記関連するカプセル化されたデータ・インスタンスのロケーションも符号化し、および
    前記論理インデックスは「ｍ」次元であり、１次元毎に「ｎ」ビットを有し、
    異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、共通性、類似性、および差異の少なくとも１つに対して比較して、前記所望する結果に対応する参照のセットを導出することにより使用されることを特徴とする、請求項３３に記載のデータ管理システム。
  37. 各々の前記少なくとも１つの次元が、複数の前記カプセル化された参照を有し、および
    異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が順番に値に基づいて記憶され、共通性、類似性、および差異の少なくとも１つに対して比較され、前記所望する結果に対応する参照のセットを導出することを特徴とする、請求項３３に記載のデータ管理システム。
  38. 比較が、前記コンピューティング環境のメモリ・バスへのポートとして取り付けられたシフトレジスタの比較機接続配列を含むハードウェア装置を使用して並列に行われることを特徴とする、請求項３３に記載のデータ管理システム。
  39. 論理回路、および連結されたサーチ結果を決定する一連のシフトレジスタを含むハードウェア装置を使用することを更に含むことを特徴とする、請求項３８に記載のデータ管理システム。
  40. ＡＳＣＩＩ文字を表現する、カプセル化されたデータ・インスタンスを更に含み、
    ＡＳＣＩＩ文字を表現する前記カプセル化されたデータ・インスタンスを含む前記共通の基本的なデータ構造も、前記対応するＡＳＣＩＩ文字を含むカプセル化されたデータ・インスタンスへのカプセル化された参照を含み、および
    前記対応するＡＳＣＩＩ文字を含む前記カプセル化されたデータ・インスタンスを含む前記共通の基本的なデータ構造も、対応するＡＳＣＩＩ文字を表現する前記カプセル化されたデータ・インスタンスへのカプセル化された参照を含むことを特徴とする、請求項１に記載のデータ管理システム。
  41. 所定のＡＳＣＩＩ文字データ・インスタンスを有する前記カプセル化された参照が、前記カプセル化されたデータ・インスタンスの前記ＡＳＣＩＩ文字の出現の順番の位置に基づいて前記ＡＳＣＩＩ文字を含む他のカプセル化されたデータ・インスタンスへの参照であることを特徴とする、請求項４０に記載のデータ管理システム。
  42. ユニコード文字を表現する、前記カプセル化されたデータ・インスタンスを更に含み、
    ユニコード文字を表現する前記カプセル化されたデータ・インスタンスを含む前記共通の基本的なデータ構造も、前記対応するユニコード文字を含むカプセル化されたデータ・インスタンスへのカプセル化された参照を含み、および
    ユニコード文字を表現する前記カプセル化されたデータ・インスタンスを含む前記共通の基本的なデータ構造も、対応するユニコード文字を表現する前記データ・インスタンスへのカプセル化された参照であることを特徴とする、請求項１に記載のデータ管理システム。
  43. 所定のユニコード文字データ・インスタンスを有する前記カプセル化された参照が、前記カプセル化されたデータ・インスタンスの前記ユニコード文字の出現の順番の位置に基づいて前記ユニコード文字を含む他のデータ・インスタンスへの参照であることを特徴とする、請求項４２に記載のデータ管理システム。
  44. 前記カプセル化されたデータ・インスタンスが、任意のデータ型のトークン・セットを表現するカプセル化されたデータ・インスタンスを含み、
    任意のデータ型のトークン・セットを表現する前記データ・インスタンスを含む前記共通の基本的なデータ構造も、任意のデータ型の前記対応するトークン・セットを含むカプセル化されたデータ・インスタンスへのカプセル化された参照を含み、および
    任意のデータ型のトークン・セットを表現する前記カプセル化されたデータ・インスタンスを含む前記共通の基本的なデータ構造も、任意のデータ型の対応するトークン・セットを表現する前記カプセル化されたデータ・インスタンスへのカプセル化された参照を含むことを特徴とする、請求項１に記載のデータ管理システム。
  45. 前記カプセル化された参照は任意のデータ型の所定のトークン・セットのためであり、データ・インスタンスが、前記カプセル化されたデータ・インスタンスの任意のデータ型の前記トークン・セットの出現の順番の位置に基づいて任意のデータ型の前記トークン・セットを含む他のカプセル化されたデータ・インスタンスへの参照であることを特徴とする、請求項４４に記載のデータ管理システム。
  46. 前記トークン・セットが、１組のグラフィック記述子、１組の色、１組の形状、１組のグリフ、１組の波形、１組の周波数値、１組の可聴周波数値、定義されたシンボルのセット、および実数のグループから選択されることを特徴とする、請求項４５に記載のデータ管理システム。
  47. ａ．前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであり、
    ｂ．選択基準を表現する前記不明のカプセル化されたデータ・インスタンスにアクセスすることにより、不明のカプセル化されたデータ・インスタンスの前記選択基準から特定の不明のカプセル化されたデータ・インスタンスを見出し、
    ｃ．前記選択基準を表現する前記不明のカプセル化されたデータ・インスタンスを用いてカプセル化された参照にアクセスし、
    ｄ．前記特定の不明のカプセル化されたデータ・インスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および
    ｅ．前記特定の不明のカプセル化されたデータ・インスタンスを検索することを特徴とする、請求項１に記載のデータ管理システム。
  48. 前記システムを検索し、異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、所望する結果を導出するために使用されることを特徴とする、請求項４７に記載のデータ管理システム。
  49. 前記カプセル化された参照の少なくとも１つが、他のコンピューティング環境のカプセル化されたデータ・インスタンスへの参照であり、および
    第１のデータ・インスタンスが、関連するデータ・インスタンスへの参照を用いてカプセル化され、前記各関連するデータ・インスタンスが、前記第１のカプセル化されたデータ・インスタンスへの参照を用いて別々にカプセル化されることを特徴とする、請求項１に記載のデータ管理システム。
  50. ａ．前記カプセル化されたデータ・インスタンスの少なくとも１つの前記カプセル化された参照が一意であり、前記カプセル化されたデータ・インスタンスの少なくとも２つの前記カプセル化された参照が一般に同一であり、
    ｂ．選択基準を表現する前記不明のカプセル化されたデータ・インスタンスにアクセスすることにより、不明のカプセル化されたデータ・インスタンスの前記選択基準から特定の不明のカプセル化されたデータ・インスタンスを見出し、
    ｃ．前記選択基準を表現する前記不明のカプセル化されたデータ・インスタンスを用いてカプセル化された参照にアクセスし、
    ｄ．前記特定の不明のカプセル化されたデータ・インスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および
    ｅ．前記特定の不明のカプセル化されたデータ・インスタンスを検索することを特徴とする、請求項１に記載のデータ管理システム。
  51. 前記カプセル化されたデータ・インスタンスの少なくとも１つの前記カプセル化された参照が一意であり、 および 前記カプセル化されたデータ・インスタンスの少なくとも２つの前記カプセル化された参照が一般に同じであり、および
    異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、所望する結果を導出するために使用される前記システムをサーチすることを特徴とする、請求項１に記載のデータ管理システム。
  52. コンピューティング環境のデータ管理システムであって、
    ａ．データ・インスタンス中心アーキテクチャを含み、
    ｂ．各データ・インスタンスが、共通の基本的なデータ構造でカプセル化され、
    ｃ．前記共通の基本的なデータ構造も、別々にカプセル化されたデータ・インスタンスに関連する参照をカプセル化し、
    ｄ．第１のデータ・インスタンスが、関連するデータ・インスタンスを参照してカプセル化され、前記各関連するデータ・インスタンスが、前記第１のカプセル化されたデータ・インスタンスを参照して別々にカプセル化され、
    ｅ．各々の前記カプセル化された参照が、各々の前記関連するカプセル化されたデータ・インスタンスを一意に識別して、各々の前記関連するカプセル化されたデータ・インスタンスのロケーションを符号化する論理インデックスであり、
    ｆ．前記論理インデックスが「ｍ」次元であり、１次元毎に「ｎ」ビットを有し、
    ｇ．前記カプセル化された参照が、少なくとも１つの次元であり、および
    各々の前記少なくとも１つの次元が、１つのタイプの関連に対応するデータ管理システム。
  53. 前記共通の基本的なデータ構造がアプリケーションに依存せず、全ての前記データ・インスタンスに対して一般的に同じであることを特徴とする、請求項５２に記載のデータ管理システム。
  54. ａ．選択基準を表現する前記不明のカプセル化されたデータ・インスタンスにアクセスすることにより、不明のカプセル化されたデータ・インスタンスの前記選択基準から特定の不明のカプセル化されたデータ・インスタンスを見出し、
    ｂ．前記選択基準を表現する前記不明のカプセル化されたデータ・インスタンスを用いてカプセル化された参照にアクセスし、
    ｃ．前記特定の不明のカプセル化されたデータ・インスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および
    ｄ．前記特定の不明のカプセル化されたデータ・インスタンスを検索することを更に含むことを特徴とする、請求項５３に記載のデータ管理システム。
  55. 前記システムを検索し、異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、所望する結果を導出するために使用されることを特徴とする、請求項５４に記載のデータ管理システム。
  56. 前記カプセル化された参照の少なくとも１つが、他のコンピューティング環境のカプセル化されたデータ・インスタンスへの参照であることを特徴とする、請求項５５に記載のデータ管理システム。
  57. 前記カプセル化されたデータ・インスタンスの少なくとも１つの前記カプセル化された参照が一意であり、前記カプセル化されたデータ・インスタンスの少なくとも２つの前記カプセル化された参照が一般に同一であることを特徴とする、請求項５６に記載のデータ管理システム。
  58. 前記システムを検索し、異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、所望する結果を導出するために使用されることを特徴とする、請求項５７に記載のデータ管理システム。
  59. ａ．選択基準を表現する前記不明のカプセル化されたデータ・インスタンスにアクセスすることにより、不明のカプセル化されたデータ・インスタンスの前記選択基準から特定の不明のカプセル化されたデータ・インスタンスを見出し、
    ｂ．前記選択基準を表現する前記不明のカプセル化されたデータ・インスタンスを用いてカプセル化された参照にアクセスし、
    ｃ．前記特定の不明のカプセル化されたデータ・インスタンスへの参照を見出すために、前記アクセスされたカプセル化された参照を比較するブール演算を使用し、および
    ｄ．前記特定の不明のカプセル化されたデータ・インスタンスを検索することを更に含むことを特徴とする、請求項５２に記載のデータ管理システム。
  60. 前記システムを検索し、異なる前記カプセル化されたデータ・インスタンスの前記カプセル化された参照が、所望する結果を導出するために使用されることを特徴とする、請求項５２に記載のデータ管理システム。
  61. 前記カプセル化された参照の少なくとも１つが、他のコンピューティング環境のカプセル化されたデータ・インスタンスへの参照であることを特徴とする、請求項５２に記載のデータ管理システム。
  62. 前記カプセル化されたデータ・インスタンスの少なくとも１つの前記カプセル化された参照が一意であり、前記カプセル化されたデータ・インスタンスの少なくとも２つの前記カプセル化された参照が一般に同一であることを特徴とする、請求項５２に記載のデータ管理システム。
  63. 物理メモリ・アドレッシングおよび論理メモリ・アドレッシングを、カプセル化されたデータ・インスタンス中心アーキテクチャで調整するための方法であって、
    各カプセル化されたデータ・インスタンスに対応して、前記カプセル化されたデータ・インスタンスに対する論理的参照が存在し、
    前記論理的参照を、第１のコンテナの前記カプセル化されたデータ・インスタンスにカプセル化し、
    前記第１のコンテナの前記論理的参照をロケーションに対する物理的参照に関連付け、前記カプセル化されたデータ・インスタンスは物理的記憶媒体に記憶され、
    前記物理的参照を第２のコンテナでカプセル化し、および
    前記第２のコンテナの前記物理的参照を、前記第１のコンテナの前記カプセル化されたデータ・インスタンスに対する前記論理的参照に関連付けることを含む方法。
  64. 前記コンテナが基本的なデータ構造であることを特徴とする、請求項６３に記載の方法。
  65. 前記物理的参照が「ｎ」次元であり、次元数および各次元のビット数が前記物理的記憶媒体の構造に対応することを特徴とする、請求項６３に記載の方法。
  66. 前記物理的記憶媒体のアドレスを計算するために前記物理的参照を使用することを特徴とする、請求項６５に記載の方法。
  67. 複数のデータ・インスタンスを調整し、および
    複数の前記論理的参照および複数の前記物理的参照を、前記第１および第２のコンテナの各々でカプセル化することを更に含むことを特徴とする、請求項６３に記載の方法。
  68. 複数の前記論理的参照を、前記第１のコンテナでソートすることを更に含むことを特徴とする、請求項６３に記載の方法。
  69. 複数の前記物理的参照を、前記第２のコンテナでソートすることを更に含むことを特徴とする、請求項６８に記載の方法。
  70. 複数の可変長データ・インスタンスを有するデータ・インスタンス中心アーキテクチャでデータ記憶を管理するための方法であって、
    前記データ・インスタンスを、一般に連続的に物理的記憶媒体で保管し、
    各データ・インスタンスを、割り当てられた各スペースで保管し、
    前記データ・インスタンスの１つを更新し、
    前記更新されたデータ・インスタンスを保管するために必要な物理スペースの量を決定することにより、前記更新されたデータ・インスタンスを前記物理的記憶媒体に組み込み、
    前記物理スペースが前記割り当てられた各スペースと等しいか、より小さいとき、前記更新されたデータ・インスタンスを前記割り当てられた各スペースに保管し、
    前記物理スペースが前記割り当てられた各スペースより大きいとき、前記物理スペースと前記割り当てられた各スペースの差に等しいか、より大きい総割り当てスペースを有する少なくとも１つの物理的に隣接するデータ・インスタンスを識別し、および
    前記更新されたデータ・インスタンスを、更新されたロケーションにおける前記物理的記憶媒体に、前記隣接するデータ・インスタンスのサイズおよび数に基づいて書き込むことを含む方法。
  71. 前記更新されたデータ・インスタンスを、更新された割り当てられた各スペースの前記物理的記憶媒体に、前記隣接するデータ・インスタンスのサイズおよび数に基づいて書き込むことを更に含むことを特徴とする、請求項７０に記載の方法。
  72. 前記少なくとも１つの物理的に隣接するデータ・インスタンスを、最後の記憶データ・インスタンスの後のロケーションに移動し、および
    前記更新されたデータ・インスタンスを、前記少なくとも１つの物理的に隣接するデータ・インスタンスのロケーションおよび前記各データ・インスタンスに対する前記物理的記憶媒体に書き込むことを更に含むことを特徴とする、請求項７０に記載の方法。
  73. 前記少なくとも１つの物理的に隣接するデータ・インスタンスを、最後の記憶データ・インスタンスの後のロケーションに移動し、および
    前記更新されたデータ・インスタンスを、前記割り当てられた各スペース、および前記移動した少なくとも１つの物理的に隣接するデータ・インスタンスの前記割り当てられたスペースの総計に等しい更新された割り当てスペースの前記物理的記憶媒体に書き込むことを更に含むことを特徴とする、請求項７０に記載の方法。
  74. 前記更新された割り当てスペースが、前記更新されたデータ・インスタンスの前記物理スペースより大きいことを特徴とする、請求項７３に記載の方法。
  75. 前記少なくとも１つの物理的に隣接するデータ・インスタンスが、前記更新されたデータ・インスタンスの後に連続的に出現することを特徴とする、請求項７０に記載の方法。
  76. 前記少なくとも１つの物理的に隣接するデータ・インスタンスが、前記更新されたデータ・インスタンスの前に連続的に出現することを特徴とする、請求項７０に記載の方法。
  77. 前記少なくとも１つの物理的に隣接するデータ・インスタンスが、前記更新されたデータ・インスタンスの前および後に連続的に出現することを特徴とする、請求項７０に記載の方法。
  78. 前記少なくとも１つの物理的に隣接するデータ・インスタンスのどれでも、前記更新されたデータ・インスタンスの前記物理スペースと前記割り当てられた各スペースの前記差に最も近く、かつより大きい割り当てられたスペースを有し、前記少なくとも１つの物理的に隣接するデータ・インスタンスは、最後の記憶データ・インスタンスの後のロケーションへ移動され、
    前記更新されたデータ・インスタンスを、前記更新されたデータ・インスタンスを、前記少なくとも１つの物理的に隣接するデータ・インスタンスのロケーションおよび前記各データ・インスタンスに対する前記物理的記憶媒体に書き込み、および
    前記更新されたデータ・インスタンスを、前記割り当てられた各スペース、および前記移動した少なくとも１つの物理的に隣接するデータ・インスタンスの前記割り当てられたスペースの総計に等しい更新された割り当てスペースの前記物理的記憶媒体に書き込むことを更に含むことを特徴とする、請求項７０に記載の方法。
  79. 前記更新されたデータ・インスタンスの前記物理スペースが、前記少なくとも１つの物理的に隣接するデータ・インスタンスの前記割り当てられたスペースよりも小さいとき、更新された データ・インスタンスが最後の記憶データ・インスタンスの後のロケーションに移動されることを特徴とする、請求項７０に記載の方法。
  80. 前記移動され更新されたデータ・インスタンスの前記割り当てられた各スペースが、前記更新されたデータ・インスタンスの前の前記物理的に隣接するデータ・インスタンスの前記割り当てられたスペースへ連続的に追加されることを特徴とする、請求項７９に記載の方法。
  81. 前記割り当てられたスペースの少なくとも１つが、前記各データ・インスタンスのサイズよりも大きいことを特徴とする、請求項７０に記載の方法。
  82. データ・インスタンス中心でないデータベースを、データ・インスタンス中心データベースに変換するための方法であって、
    データ・インスタンスを、前記データ・インスタンス中心でないデータベース・スキーマの要素、および前記データ・インスタンス中心でないデータベースのデータ要素を表現する前記データ・インスタンス中心データベースで創出し、および
    関連を、前記データ・インスタンス in 前記データ要素と前記データ・インスタンス中心でないデータベースの前記スキーマ要素の間の関係を表現する前記データ中心データベースの間に創出することを含む方法。
  83. 前記変換が、前記データ・インスタンス中心データベースのデータ・インスタンスであるソフトウェア・エージェントによることを特徴とする、請求項８２に記載の方法。
  84. 前記データ・インスタンス中心でないデータベースが、単層ファイルを含むことを特徴とする、請求項８２に記載の方法。
  85. データ管理システムであって、
    １または複数のアイテムを含み、
    前記各アイテムが、データ・インスタンスをカプセル化し、および
    アイテムが、他の各カプセル化相互参照に関連することを特徴とするデータ管理システム。
  86. 前記各アイテムが、基本的なデータ構造で表されることを特徴とする、請求項８５に記載のデータ管理システム。
  87. 前記各アイテムが、関連する一意な参照を有することを特徴とする、請求項８５に記載のデータ管理システム。
  88. 前記一意な参照も、前記各アイテムに関連する前記データ・インスタンスを物理的に配置するインデックスとして機能することを特徴とする、請求項８７に記載のデータ管理システム。
  89. 前記参照が、前記アイテムとセットで参照された他の各アイテムの間の関連の型を定義する前記セットで配置されるアイテムに関連付けられることを特徴とする、請求項８５に記載のデータ管理システム。
  90. 前記各参照 が「ｍ」次元インデックスであり、前記各次元が「ｎ」ビット長であることを特徴とする、請求項８７に記載のデータ管理システム。
  91. 「ｍ」が４であり、「ｎ」が３０であることを特徴とする、請求項９０に記載のデータ管理システム。
  92. 前記アイテムが、１または複数の他のメンバ・アイテムのためのコンテナとして機能することを特徴とする、請求項８５に記載のデータ管理システム。
  93. コンテナ・アイテムの内部のアイテムのメンバシップが、前記コンテナ・アイテムおよび前記各メンバ・アイテムの前記論理インデックスの１または複数の前記「ｍ」次元の識別により示されることを特徴とする、請求項９２に記載のデータ管理システム。
  94. 前記各アイテムが、埋込要素をカプセル化することを特徴とする、請求項８５に記載のデータ管理システム。
  95. 前記埋込要素が、他のアイテムへの参照であることを特徴とする、請求項９４に記載のデータ管理システム。
  96. 前記データ・インスタンスが、任意の型のデータを含むことを特徴とする、請求項８５に記載のデータ管理システム。
JP2004525705A 2002-07-26 2003-07-16 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ Pending JP2005534121A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US39884302P 2002-07-26 2002-07-26
US45720703P 2003-03-25 2003-03-25
PCT/IB2003/003690 WO2004013770A2 (en) 2002-07-26 2003-07-16 Data management architecture associating generic data items using reference

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2011227239A Division JP5833406B2 (ja) 2002-07-26 2011-10-14 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ

Publications (1)

Publication Number Publication Date
JP2005534121A true JP2005534121A (ja) 2005-11-10

Family

ID=31498594

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2004525705A Pending JP2005534121A (ja) 2002-07-26 2003-07-16 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ
JP2011227239A Expired - Lifetime JP5833406B2 (ja) 2002-07-26 2011-10-14 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2011227239A Expired - Lifetime JP5833406B2 (ja) 2002-07-26 2011-10-14 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ

Country Status (13)

Country Link
US (1) US8051102B2 (ja)
EP (1) EP1525541A2 (ja)
JP (2) JP2005534121A (ja)
CN (1) CN1856783B (ja)
AU (1) AU2003253196A1 (ja)
BR (1) BR0312989A (ja)
CA (1) CA2493352C (ja)
FI (1) FI20050083A (ja)
HK (1) HK1098842A1 (ja)
IL (1) IL166472A (ja)
NO (1) NO20051073L (ja)
RU (1) RU2005105582A (ja)
WO (1) WO2004013770A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008547086A (ja) * 2005-06-15 2008-12-25 インターレース・システムズ・インコーポレイテッド 大きなデータセットの解析中に整合性を維持するための方法および装置
JP2009503664A (ja) * 2005-07-25 2009-01-29 エアバス 乗り物に乗っている操縦者とその環境の間のインターフェイスをモデル化する方法とシステム

Families Citing this family (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6738077B1 (en) * 2000-07-18 2004-05-18 Apple Computer, Inc. Dynamic generation and automated distribution of user interface from database model
US7395027B2 (en) 2002-08-15 2008-07-01 Seitz Thomas R Computer-aided education systems and methods
AU2003282342A1 (en) * 2002-11-13 2004-06-03 Kenneth, Nadav Method and system for using query information to enhance categorization and navigation within the whole knowledge base
US7941453B1 (en) 2003-05-09 2011-05-10 Vignette Software Llc Method and system for deployment of content using proxy objects
US7337176B1 (en) * 2003-08-29 2008-02-26 Sprint Communications Company L.P. Data loading tool for loading a database
US8869061B1 (en) 2003-08-29 2014-10-21 Microsoft Corporation User interface for searching an electronic document
US20060211824A1 (en) * 2003-09-05 2006-09-21 Harumi Sakamoto Polyolefin graft copolymer, composition and method for producing same
US7590936B1 (en) * 2003-09-30 2009-09-15 Microsoft Corporation Method for extracting information associated with a search term
US20050076003A1 (en) * 2003-10-06 2005-04-07 Dubose Paul A. Method and apparatus for delivering personalized search results
US7333994B2 (en) * 2003-12-18 2008-02-19 Microsoft Corporation System and method for database having relational node structure
US8037102B2 (en) 2004-02-09 2011-10-11 Robert T. and Virginia T. Jenkins Manipulating sets of hierarchical data
CA2556023A1 (en) * 2004-02-20 2005-09-09 Dow Jones Reuters Business Interactive, Llc Intelligent search and retrieval system and method
US7647356B2 (en) * 2004-05-07 2010-01-12 Oracle International Corporation Methods and apparatus for facilitating analysis of large data sets
US9646107B2 (en) * 2004-05-28 2017-05-09 Robert T. and Virginia T. Jenkins as Trustee of the Jenkins Family Trust Method and/or system for simplifying tree expressions such as for query reduction
US7620632B2 (en) * 2004-06-30 2009-11-17 Skyler Technology, Inc. Method and/or system for performing tree matching
US7698333B2 (en) * 2004-07-22 2010-04-13 Factiva, Inc. Intelligent query system and method using phrase-code frequency-inverse phrase-code document frequency module
EP1645992A1 (en) * 2004-10-08 2006-04-12 Philip Morris Products S.A. Methods and systems for marking, tracking and authentication of products
US7627591B2 (en) * 2004-10-29 2009-12-01 Skyler Technology, Inc. Method and/or system for manipulating tree expressions
US7801923B2 (en) * 2004-10-29 2010-09-21 Robert T. and Virginia T. Jenkins as Trustees of the Jenkins Family Trust Method and/or system for tagging trees
US7630995B2 (en) 2004-11-30 2009-12-08 Skyler Technology, Inc. Method and/or system for transmitting and/or receiving data
US7636727B2 (en) 2004-12-06 2009-12-22 Skyler Technology, Inc. Enumeration of trees from finite number of nodes
US8316059B1 (en) 2004-12-30 2012-11-20 Robert T. and Virginia T. Jenkins Enumeration of rooted partial subtrees
US20060179055A1 (en) * 2005-01-05 2006-08-10 Jim Grinsfelder Wine categorization system and method
US8615530B1 (en) 2005-01-31 2013-12-24 Robert T. and Virginia T. Jenkins as Trustees for the Jenkins Family Trust Method and/or system for tree transformation
US7681177B2 (en) 2005-02-28 2010-03-16 Skyler Technology, Inc. Method and/or system for transforming between trees and strings
US8356040B2 (en) 2005-03-31 2013-01-15 Robert T. and Virginia T. Jenkins Method and/or system for transforming between trees and arrays
US7899821B1 (en) 2005-04-29 2011-03-01 Karl Schiffmann Manipulation and/or analysis of hierarchical data
US20070021993A1 (en) * 2005-07-22 2007-01-25 Ankur Chandra Method and system for constructing, managing and using enterprise architecture in a component busines model
US7707485B2 (en) * 2005-09-28 2010-04-27 Vixs Systems, Inc. System and method for dynamic transrating based on content
WO2007104611A2 (en) * 2006-03-14 2007-09-20 International Business Machines Corporation Input data structure for data mining
JP2007265031A (ja) * 2006-03-28 2007-10-11 Toshiba Corp 辞書コンテンツ処理装置、コンテンツ表示システムおよびコンテンツ表示方法
US7831563B2 (en) * 2006-05-17 2010-11-09 International Business Machines Corporation Active storage and retrieval systems and methods
US7739221B2 (en) * 2006-06-28 2010-06-15 Microsoft Corporation Visual and multi-dimensional search
US7917514B2 (en) 2006-06-28 2011-03-29 Microsoft Corporation Visual and multi-dimensional search
US7533085B2 (en) * 2006-08-14 2009-05-12 International Business Machines Corporation Method for searching deep web services
US7603366B1 (en) * 2006-09-27 2009-10-13 Emc Corporation Universal database schema and use
US7856431B2 (en) * 2006-10-24 2010-12-21 Merced Systems, Inc. Reporting on facts relative to a specified dimensional coordinate constraint
US7814052B2 (en) 2006-11-03 2010-10-12 Salesforce.Com, Inc. Implementing formulas for custom fields in an on-demand database
US20080114733A1 (en) * 2006-11-14 2008-05-15 Microsoft Corporation User-structured data table indexing
US20080140653A1 (en) * 2006-12-08 2008-06-12 Matzke Douglas J Identifying Relationships Among Database Records
US8583592B2 (en) * 2007-03-30 2013-11-12 Innography, Inc. System and methods of searching data sources
US20080243787A1 (en) * 2007-03-30 2008-10-02 Tyron Jerrod Stading System and method of presenting search results
US9626421B2 (en) 2007-09-21 2017-04-18 Hasso-Plattner-Institut Fur Softwaresystemtechnik Gmbh ETL-less zero-redundancy system and method for reporting OLTP data
US8051075B2 (en) * 2007-09-24 2011-11-01 Merced Systems, Inc. Temporally-aware evaluative score
WO2009046021A1 (en) * 2007-10-01 2009-04-09 Rosetta Inpharmatics Llc Integrated genomic system
US8190646B2 (en) * 2008-01-02 2012-05-29 International Business Machines Corporation Associative object model for composite entity information
US7970728B2 (en) * 2008-10-23 2011-06-28 International Business Machines Corporation Dynamically building and populating data marts with data stored in repositories
US8478765B2 (en) * 2008-12-29 2013-07-02 Plutopian Corporation Method and system for compiling a multi-source database of composite investor-specific data records with no disclosure of investor identity
US8346800B2 (en) * 2009-04-02 2013-01-01 Microsoft Corporation Content-based information retrieval
US8321390B2 (en) * 2009-06-11 2012-11-27 Vivek Swarnakar Methods and apparatus for organizing data in a database
US8422859B2 (en) * 2010-03-23 2013-04-16 Vixs Systems Inc. Audio-based chapter detection in multimedia stream
US8407228B1 (en) * 2010-03-26 2013-03-26 Cadence Design Systems, Inc Method and mechanism for maintaining existence information for electronic layout data
US8504876B2 (en) * 2010-04-30 2013-08-06 The Mitre Corporation Anomaly detection for database systems
CN102456176B (zh) * 2010-10-27 2015-01-14 金蝶软件（中国）有限公司 一种物料清单工程变更的方法及装置
US9465836B2 (en) * 2010-12-23 2016-10-11 Sap Se Enhanced business object retrieval
EP2472451A1 (en) 2010-12-30 2012-07-04 Philip Morris Products S.A. Method and apparatus for marking manufactured items
US20120278290A1 (en) * 2011-04-29 2012-11-01 Thomas Anthony Pinch Database archiving model error detection and correction system
RU2480826C2 (ru) * 2011-07-22 2013-04-27 Федеральное государственное автономное образовательное учреждение высшего профессионального образования "Уральский федеральный университет имени первого Президента России Б.Н. Ельцина" Система управления знаниями для разрешения ситуаций
US8577938B2 (en) * 2011-08-23 2013-11-05 Accenture Global Services Limited Data mapping acceleration
US8930398B1 (en) * 2011-10-11 2015-01-06 Careerimp, Inc. System and method for improving a resume according to a job description
US8751505B2 (en) * 2012-03-11 2014-06-10 International Business Machines Corporation Indexing and searching entity-relationship data
CN102831217B (zh) * 2012-08-17 2015-03-04 安科智慧城市技术（中国）有限公司 一种数据处理方法及装置
US8996544B2 (en) 2012-09-28 2015-03-31 Oracle International Corporation Pruning disk blocks of a clustered table in a relational database management system
US9507825B2 (en) 2012-09-28 2016-11-29 Oracle International Corporation Techniques for partition pruning based on aggregated zone map information
US9430550B2 (en) 2012-09-28 2016-08-30 Oracle International Corporation Clustering a table in a relational database management system
US8892576B2 (en) * 2012-10-26 2014-11-18 International Business Machines Corporation Ordering and presenting a set of data tuples
US9087085B2 (en) 2012-12-10 2015-07-21 International Business Machines Corporation Pre-assimilation values and post-assimilation values in hardware instance identifiers
WO2014122295A2 (en) * 2013-02-07 2014-08-14 Qatar Foundation Methods and systems for data cleaning
US9665403B2 (en) 2013-03-15 2017-05-30 Miosoft Corporation Executing algorithms in parallel
US10642837B2 (en) 2013-03-15 2020-05-05 Oracle International Corporation Relocating derived cache during data rebalance to maintain application performance
US9613112B2 (en) 2013-03-15 2017-04-04 Miosoft Corporation Structuring data
CN103577590A (zh) * 2013-11-12 2014-02-12 北京润乾信息系统技术有限公司 一种数据查询方法和系统
US9418124B2 (en) * 2013-12-16 2016-08-16 International Business Machines Corporation System and method of integrating time-aware data from multiple sources
CN103955526B (zh) * 2014-05-09 2017-05-10 中国联合网络通信集团有限公司 数据存储方法和装置
US10333696B2 (en) 2015-01-12 2019-06-25 X-Prime, Inc. Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency
EP3051469B1 (en) 2015-01-28 2024-05-22 Inexto Sa Method and apparatus for unit and container identification and tracking
PL3051372T3 (pl) 2015-01-31 2019-10-31 Inexto Sa Zabezpieczona identyfikacja i weryfikacja produktu
US10289706B2 (en) 2015-06-03 2019-05-14 International Business Machines Corporation Repairing corrupted references
US20180205543A1 (en) 2015-08-13 2018-07-19 Inexto Sa Enhanced obfuscation or randomization for secure product identification and verification
US10025565B2 (en) * 2015-08-19 2018-07-17 Integrator Software Integrated software development environments, systems, methods, and memory models
EP3341880B1 (en) 2015-08-25 2022-03-30 Inexto Sa Verification with error tolerance for secure product identifiers
US10594494B2 (en) 2015-08-25 2020-03-17 Inexto Sa Multiple authorization modules for secure production and verification
CN106682030A (zh) * 2015-11-10 2017-05-17 阿里巴巴集团控股有限公司 信息处理方法及装置
US10599676B2 (en) 2015-12-15 2020-03-24 Microsoft Technology Licensing, Llc Replication control among redundant data centers
US10248709B2 (en) 2015-12-15 2019-04-02 Microsoft Technology Licensing, Llc Promoted properties in relational structured data
US11226985B2 (en) 2015-12-15 2022-01-18 Microsoft Technology Licensing, Llc Replication of structured data records among partitioned data storage spaces
US10235406B2 (en) 2015-12-15 2019-03-19 Microsoft Technology Licensing, Llc Reminder processing of structured data records among partitioned data storage spaces
US9697239B1 (en) * 2016-04-15 2017-07-04 Lars Dierk Buchholz Token-based database system and method of interfacing with the token-based database system
CN105956012B (zh) * 2016-04-21 2019-04-23 哈尔滨工程大学 基于图划分策略的数据库模式抽象方法
US10540332B2 (en) * 2016-08-03 2020-01-21 Microsoft Technology Licensing, Llc Efficient denormalization of data instances
US10572502B2 (en) * 2016-12-21 2020-02-25 Iwasaki Electric Mfg. Co., Ltd. Data table production device, data table production method, and data table production program
US10719555B2 (en) * 2017-02-07 2020-07-21 Salesforce.Com, Inc. System and method in a database system for sharing a data item with an entity in another tenant domain
CN107203784B (zh) * 2017-05-24 2020-06-12 南京秦淮紫云创益企业服务有限公司 一种相似度计算方法、终端及计算机可读存储介质
US11086876B2 (en) 2017-09-29 2021-08-10 Oracle International Corporation Storing derived summaries on persistent memory of a storage device
US11182394B2 (en) 2017-10-30 2021-11-23 Bank Of America Corporation Performing database file management using statistics maintenance and column similarity
KR102557572B1 (ko) * 2018-05-23 2023-07-24 한국전자통신연구원 인공 신경망 장치 및 그 동작 방법
US11914612B2 (en) * 2018-09-24 2024-02-27 Salesforce, Inc. Selective synchronization of linked records
US11048761B2 (en) * 2018-12-13 2021-06-29 Business Objects Software Ltd. Semantic contextual element linking
US11651274B2 (en) * 2019-07-10 2023-05-16 Here Global B.V. Method, apparatus, and system for providing semantic filtering
US11113284B2 (en) * 2019-08-09 2021-09-07 Sap Se Virtual backward associations for generic request handling based on models
CN110765159B (zh) * 2019-11-01 2022-08-12 上海达梦数据库有限公司 对象解析方法、装置、存储介质及设备
CN111143353B (zh) * 2019-12-04 2023-04-14 中国航空工业集团公司西安飞行自动控制研究所 更改单中提取bom变化数据的方法
US11321285B2 (en) 2020-10-01 2022-05-03 Bank Of America Corporation Automatic database script generation for copying data between relational databases
WO2022093206A1 (en) * 2020-10-28 2022-05-05 Hewlett-Packard Development Company, L.P. Dimensionality reduction
CN112842261B (zh) * 2020-12-30 2021-12-28 西安交通大学 一种基于复杂网络的婴儿三维自发运动智能化评估系统
US20220215310A1 (en) * 2021-01-07 2022-07-07 Ritual Mobile, Inc. Automatically generating parameters for enterprise programs and initiatives
US20220253718A1 (en) * 2021-02-09 2022-08-11 Red Hat, Inc. Automatically validating decision tables
CN113505127B (zh) * 2021-06-22 2024-06-18 侍意(厦门)网络信息技术有限公司 对有关联性对象的数据的存储结构及方法、检索和可视化展示方法
CN114579553B (zh) * 2022-03-07 2023-04-11 中国标准化研究院 一种数据质量保证方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0195324A (ja) * 1987-10-07 1989-04-13 Ricoh Co Ltd データベース管理システムの拡張機構
JPH06332710A (ja) * 1993-05-21 1994-12-02 Fujitsu Ltd オブジェクト指向データ処理システム

Family Cites Families (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US555409A (en) * 1896-02-25 squire
IE52820B1 (en) * 1982-05-07 1988-03-16 William F Murray A sports proctice glove
US4591983A (en) 1984-07-09 1986-05-27 Teknowledge, Inc. Hierarchical knowledge system
US4816994A (en) 1984-12-04 1989-03-28 Tektronix, Inc. Rule acquisition for expert systems
JPS62128332A (ja) 1985-11-30 1987-06-10 Toshiba Corp デ−タ処理装置
US4868763A (en) 1986-02-21 1989-09-19 Hitachi, Ltd. Knowledge-based system having plural processors
JPS62293352A (ja) 1986-06-11 1987-12-19 Hitachi Ltd 知識情報処理システム
US4752889A (en) 1986-08-18 1988-06-21 Neuron Data, Inc. Dynamic, interactive display system for a knowledge base
US4884218A (en) 1987-10-01 1989-11-28 International Business Machines Corporation Knowledge system with improved request processing
JPH032939A (ja) 1989-05-30 1991-01-09 Hitachi Ltd データ管理方法
US5490258A (en) 1991-07-29 1996-02-06 Fenner; Peter R. Associative memory for very large key spaces
US5333237A (en) 1989-10-10 1994-07-26 Hughes Aircraft Company Hypermedia structured knowledge base system
US5448726A (en) 1989-10-23 1995-09-05 International Business Machines Corporation Data base management system with data dictionary cache including a single loadable object descriptor
JPH0727447B2 (ja) * 1990-07-05 1995-03-29 富士ゼロックス株式会社 ハイパーメディア装置
US5555409A (en) 1990-12-04 1996-09-10 Applied Technical Sysytem, Inc. Data management systems and methods including creation of composite views of data
US6424989B1 (en) 1991-09-20 2002-07-23 Venson M. Shaw Object-oriented transaction computing system
US6400996B1 (en) 1999-02-01 2002-06-04 Steven M. Hoffberg Adaptive pattern recognition based control system and method
US5555388A (en) 1992-08-20 1996-09-10 Borland International, Inc. Multi-user system and methods providing improved file management by reading
US5448722A (en) 1993-03-10 1995-09-05 International Business Machines Corporation Method and system for data processing system error diagnosis utilizing hierarchical blackboard diagnostic sessions
US5701453A (en) 1993-07-01 1997-12-23 Informix Software, Inc. Logical schema to allow access to a relational database without using knowledge of the database structure
AU679553B2 (en) 1993-07-07 1997-07-03 European Computer-Industry Research Centre Gmbh Database structures
US5548749A (en) * 1993-10-29 1996-08-20 Wall Data Incorporated Semantic orbject modeling system for creating relational database schemas
US5584024A (en) * 1994-03-24 1996-12-10 Software Ag Interactive database query system and method for prohibiting the selection of semantically incorrect query parameters
US5974141A (en) 1995-03-31 1999-10-26 Mitsubishi Corporation Data management system
EP0682318B1 (de) 1994-05-10 2000-08-09 Siemens Aktiengesellschaft Datenverwaltungssystem
US5649190A (en) 1994-06-14 1997-07-15 Harris Corporation Multi-model database system for dynamic creation and maintenance of complex objects in a real time environment
US5619621A (en) 1994-07-15 1997-04-08 Storage Technology Corporation Diagnostic expert system for hierarchically decomposed knowledge domains
US6301581B1 (en) 1994-08-01 2001-10-09 Texas Instruments Incorporated Method and system for managing access to a plurality of data objects
US5726898A (en) 1994-09-01 1998-03-10 American Greetings Corporation Method and apparatus for storing and selectively retrieving and delivering product data based on embedded expert judgements
US5611076A (en) 1994-09-21 1997-03-11 Micro Data Base Systems, Inc. Multi-model database management system engine for databases having complex data models
US6002772A (en) 1995-09-29 1999-12-14 Mitsubishi Corporation Data management system
US6076077A (en) 1995-10-27 2000-06-13 Mitsubishi Corporation Data management system
US5592666A (en) 1994-10-31 1997-01-07 Sinper Corporation Method and system for storing and retrieving data from a multidimensional array using database pointers
US5799157A (en) 1994-12-13 1998-08-25 Elcom Systems, Inc. System and method for creating interactive electronic systems to present information and execute transactions
US6134549A (en) 1995-03-31 2000-10-17 Showcase Corporation Client/server computer system having personalizable and securable views of database data
US6067552A (en) 1995-08-21 2000-05-23 Cnet, Inc. User interface system and method for browsing a hypertext database
US5671406A (en) 1995-10-18 1997-09-23 Digital Equipment Corporation Data structure enhancements for in-place sorting of a singly linked list
US6425119B1 (en) 1996-10-09 2002-07-23 At&T Corp Method to produce application oriented languages
US6037944A (en) 1996-11-07 2000-03-14 Natrificial Llc Method and apparatus for displaying a thought network from a thought's perspective
US5905989A (en) 1996-11-27 1999-05-18 Bently Nevada Corporation Knowledge manager relying on a hierarchical default expert system: apparatus and method
JPH10161923A (ja) * 1996-11-28 1998-06-19 Toshiba Corp オブジェクト指向データベース管理装置
US6088693A (en) 1996-12-06 2000-07-11 International Business Machines Corporation Data management system for file and database management
US5920867A (en) 1996-12-06 1999-07-06 International Business Machines Corporation Data management system having data management configuration
US5878408A (en) 1996-12-06 1999-03-02 International Business Machines Corporation Data management system and process
US5822780A (en) 1996-12-31 1998-10-13 Emc Corporation Method and apparatus for hierarchical storage management for data base management systems
US5745228A (en) * 1997-01-17 1998-04-28 Embrex, Inc. Method and apparatus for distinguishing live from infertile poultry eggs
JPH10214218A (ja) * 1997-01-30 1998-08-11 Meidensha Corp データベース管理システム
US5873049A (en) * 1997-02-21 1999-02-16 Atlantic Richfield Company Abstraction of multiple-format geological and geophysical data for oil and gas exploration and production analysis
US6115716A (en) 1997-03-14 2000-09-05 Nokia Telecommunications Oy Method for implementing an associative memory based on a digital trie structure
US6073111A (en) 1997-04-15 2000-06-06 International Business Machines Corporation Container materialization/dematerialization for reduced dataload and improved data-coherency in workflow-management systems
US5991758A (en) 1997-06-06 1999-11-23 Madison Information Technologies, Inc. System and method for indexing information about entities from different information sources
US6236997B1 (en) 1997-06-23 2001-05-22 Oracle Corporation Apparatus and method for accessing foreign databases in a heterogeneous database system
US6205447B1 (en) 1997-06-30 2001-03-20 International Business Machines Corporation Relational database management of multi-dimensional data
US6016497A (en) * 1997-12-24 2000-01-18 Microsoft Corporation Methods and system for storing and accessing embedded information in object-relational databases
US6101500A (en) 1998-01-07 2000-08-08 Novell, Inc. System and method for managing objects in a hierarchical data structure
US6233586B1 (en) 1998-04-01 2001-05-15 International Business Machines Corp. Federated searching of heterogeneous datastores using a federated query object
US6212530B1 (en) 1998-05-12 2001-04-03 Compaq Computer Corporation Method and apparatus based on relational database design techniques supporting modeling, analysis and automatic hypertext generation for structured document collections
US6112209A (en) 1998-06-17 2000-08-29 Gusack; Mark David Associative database model for electronic-based informational assemblies
WO2000004483A2 (en) 1998-07-15 2000-01-27 Imation Corp. Hierarchical data storage management
JP2000090098A (ja) 1998-09-09 2000-03-31 Hitachi Ltd データベース問い合わせ方法及びその実施装置並びにその処理プログラムを記録した媒体
KR20010093775A (ko) 1998-09-30 2001-10-29 아이투 테크놀로지스 인코포레이티드 다차원 데이터 관리 시스템
US6317749B1 (en) 1998-09-30 2001-11-13 Daman, Inc. Method and apparatus for providing relationship objects and various features to relationship and other objects
JP2000112797A (ja) 1998-10-02 2000-04-21 Nippon Telegr & Teleph Corp <Ntt> ビューディレクトリ処理方法および装置とビューディレクトリ処理プログラムを記録した記録媒体
US6029174A (en) 1998-10-31 2000-02-22 M/A/R/C Inc. Apparatus and system for an adaptive data management architecture
US6185555B1 (en) 1998-10-31 2001-02-06 M/A/R/C Inc. Method and apparatus for data management using an event transition network
US6327594B1 (en) 1999-01-29 2001-12-04 International Business Machines Corporation Methods for shared data management in a pervasive computing environment
US6408321B1 (en) 1999-03-24 2002-06-18 International Business Machines Corporation Method and apparatus for mapping components of descriptor vectors to a space that discriminates between groups
US6385604B1 (en) 1999-08-04 2002-05-07 Hyperroll, Israel Limited Relational database management system having integrated non-relational multi-dimensional data store of aggregated data elements
US6470354B1 (en) * 1999-08-05 2002-10-22 International Business Machines Corporation Implementing persistent object services (POS) on top of a relational database
FI19992256A (fi) 1999-10-19 2001-04-20 Camsofta Oy Valmistuslaitoksen suunnittelu ja hallinto
US6484179B1 (en) 1999-10-25 2002-11-19 Oracle Corporation Storing multidimensional data in a relational database management system
FR2801118B1 (fr) * 1999-11-17 2001-12-21 Bull Cp8 Procede de chargement d'applications dans un systeme embarque multi-application, systeme embarque correspondant, et procede d'execution d'une application du systeme embarque
WO2001077904A1 (en) 2000-04-11 2001-10-18 Revelink, Inc. Framework for creation, update, query, and view navigation of data objects and textual annotations of relations between data objects
US6609132B1 (en) * 2000-04-11 2003-08-19 Revelink, Inc. Object data model for a framework for creation, update and view navigation of data objects and textual annotations of relations between data objects
US6957214B2 (en) * 2000-06-23 2005-10-18 The Johns Hopkins University Architecture for distributed database information access
US20020069240A1 (en) * 2000-12-06 2002-06-06 Berk Donald J. Method and apparatus for electronically updating printed publications
US6704432B2 (en) * 2001-10-18 2004-03-09 Microsoft Corporation Extensible file format
CA2465378A1 (en) * 2001-11-09 2003-05-15 British Telecommunications Public Limited Company Visual representation of data within a database
US7962011B2 (en) * 2001-12-06 2011-06-14 Plourde Jr Harold J Controlling substantially constant buffer capacity for personal video recording with consistent user interface of available disk space
WO2003089082A1 (en) * 2002-04-18 2003-10-30 Walker Digital, Llc Method and apparatus for providing a bonus to a player based on a credit balance
US20030227487A1 (en) 2002-06-01 2003-12-11 Hugh Harlan M. Method and apparatus for creating and accessing associative data structures under a shared model of categories, rules, triggers and data relationship permissions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0195324A (ja) * 1987-10-07 1989-04-13 Ricoh Co Ltd データベース管理システムの拡張機構
JPH06332710A (ja) * 1993-05-21 1994-12-02 Fujitsu Ltd オブジェクト指向データ処理システム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008547086A (ja) * 2005-06-15 2008-12-25 インターレース・システムズ・インコーポレイテッド 大きなデータセットの解析中に整合性を維持するための方法および装置
JP2009503664A (ja) * 2005-07-25 2009-01-29 エアバス 乗り物に乗っている操縦者とその環境の間のインターフェイスをモデル化する方法とシステム

Also Published As

Publication number Publication date
US8051102B2 (en) 2011-11-01
JP2012043456A (ja) 2012-03-01
CN1856783B (zh) 2011-05-25
IL166472A (en) 2013-08-29
AU2003253196A8 (en) 2004-02-23
CA2493352C (en) 2015-05-19
WO2004013770A3 (en) 2004-08-12
JP5833406B2 (ja) 2015-12-16
FI20050083A (fi) 2005-01-26
AU2003253196A1 (en) 2004-02-23
CA2493352A1 (en) 2004-02-12
EP1525541A2 (en) 2005-04-27
NO20051073L (no) 2005-04-19
WO2004013770A2 (en) 2004-02-12
HK1098842A1 (en) 2007-07-27
US20040024790A1 (en) 2004-02-05
BR0312989A (pt) 2008-03-04
RU2005105582A (ru) 2005-10-10
CN1856783A (zh) 2006-11-01

Similar Documents

Publication Publication Date Title
JP5833406B2 (ja) 参照を使用してジェネリック・データ・アイテムに関連するデータ管理アーキテクチャ
US7734657B2 (en) Containment hierarchy in a database system
US5899992A (en) Scalable set oriented classifier
US7171427B2 (en) Methods of navigating a cube that is implemented as a relational object
US6484181B2 (en) Method and system for handling foreign key update in an object-oriented database environment
US20040015516A1 (en) Object graph faulting and trimming in an object-relational database system
US7613715B2 (en) Map and data location provider
ZA200100187B (en) Value-instance-connectivity computer-implemented database.
Markov et al. Natural Language Addressing
Yaseen et al. An extensible kernel object management system
Chen An object-oriented database system for efficient information retrieval applications
Powell Oracle high performance tuning for 9i and 10g
Shekita High Performance Implementation Techniques for Next Generation Database Systems
Eze et al. Database system concepts, implementations and organizations-a detailed survey
Cheiney et al. Relational storage and efficient retrieval of rules in a deductive DBMS
Meghini et al. Conceptual document modelling and retrieval
Ramsak Towards a general-purpose, multidimensional index: Integration, Optimization and Enhancement of UB-Trees
Gupta Taxonomy of Database Management System
Al-Hajj Storage management and indexing in object-oriented database management systems
Meads Clustering strategies for object databases
QTAISH XANCESTOR: A MAPPING APPROACH FOR STORING AND QUERYING XML DOCUMENTS IN RELATIONAL DATABASE USING PATH-BASED
Shahabi About InfoLab
Ndakunda Extensibility in ORDBMS Databases: An Exploration of the Data Cartridge Mechanism in Oracle9i
Topor Safety and Domain Independence.
Liu Performance evaluation of object-oriented databases

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060123

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090908

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20091208

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20091208

RD13 Notification of appointment of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7433

Effective date: 20091208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091208

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20091208

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100108

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100112

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100308

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100518

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100818

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100825

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100917

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100928

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20101018

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20101025

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101118

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110614

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20111014

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111014