CN1856783A - 使用参考与一般数据项关联的数据管理结构 - Google Patents

使用参考与一般数据项关联的数据管理结构 Download PDF

Info

Publication number
CN1856783A
CN1856783A CNA038227444A CN03822744A CN1856783A CN 1856783 A CN1856783 A CN 1856783A CN A038227444 A CNA038227444 A CN A038227444A CN 03822744 A CN03822744 A CN 03822744A CN 1856783 A CN1856783 A CN 1856783A
Authority
CN
China
Prior art keywords
data
packed
data instance
quoting
instance
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.)
Granted
Application number
CNA038227444A
Other languages
English (en)
Other versions
CN1856783B (zh
Inventor
罗恩·埃弗里特
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Publication of CN1856783A publication Critical patent/CN1856783A/zh
Application granted granted Critical
Publication of CN1856783B publication Critical patent/CN1856783B/zh
Anticipated expiration legal-status Critical
Expired - Fee Related 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的优先权。
技术领域
本发明涉及数据管理领域，通常称为数据库管理系统或DBMS。
背景技术
最早的面向商务的数据处理应用包括根据类似记录的结构收集到平面文件(flat file)中的信息内容的记录(record)。企业中的每个部门尝试独立用计算机管理其大量数据的功能(例如发票处理、客户帐单)。某些方面的企业数据被任意重复或复制，因为信息的这些平面文件是为独立的软件应用程序的每个方面特别设计的。平面文件中数据冗余程度很高，这使得信息非常难以被完全更新，并且常导致软件应用程序给出错误的答案或者采取不当的操作。平面文件计算还意味着企业不能查看跨部门信息范围的数据。每个软件应用程序使用由硬件制造商提供的唯一的物理数据储存设计和基本设备访问方法，以便实现应用程序内的物理数据管理。数据处理的平面文件方法极易出错并且花费昂贵，并且不提供企业的战略视图。
这一情况引起了对从功能性软件应用程序中分离出物理数据管理并且创建独立的可重用的、唯一用途是物理数据库管理的应用程序的普遍寻求。这些应用程序被称为数据库管理系统或DBMS。
由于企业数据通常具有平面文件(即所有结构复杂性都被平面化为二维的，从而有了“平面”这个说法)中几乎不可能捕捉的高度的结构复杂性，独立DBMS的首次尝试使用了很大程度上非冗余信息的较小记录，这些记录带有分级或网状“指针”。为了在这些DBMS间做出选择必须确定数据本来是分级的还是网状的。这两种方法都被证明为具有有限的可缩放性。由于这些和其他原因，分级和网状DBMS只取得了有限的商业成功。
1970年，IBM的E.F.(Ted)Codd发表了一种用于大型的共享数据库的数据储存和检索的关系模型(CODD，E.F.，“A RelationalModel of Data for Large Shared Data Banks”，Communications of theACM 13，6(June，1970)，pp.377-387，以下称为[Cod70])。Ted Codd的管理冗余性有限的数据库记录的模型是一种集合理论(数学)模型，它同等对待数据内容，不论其根本结构是分级的还是面向网络的。虽然Ted Codd的方法很精致且通用，但是在八十年代它并没有被广泛采用，因为那时候的大型计算机不能支持关系DBMS(RDBMS)所要求的输入/输出强度。随着八十年代硬件能力的增强，大部分工业从业者开始排队等候Codd的RDMS，将其作为管理大型共享数据库的最佳手段。虽然现在仍有成千上万的面向商业的软件应用程序仍以平面文件和分级或基于网络的DBMS来进行操作，但是这些管理企业数据库的方法被认为是已过时的了。信息更新现在是由RDBMS实现的在线事务处理器(OLTP)站点的天下了。大型复杂查询越来越多地由称为数据仓库(DWH)的专业应用程序来处理，这种数据仓库是操作在Codd的关系模型的痕迹之上的。Ted Codd的关系模型现在雄距整个企业计算世界。
虽然关系模型作为数据库管理机制几乎被全世界所认可，但是此模型中有巨大的问题。最重大的问题是缺乏关系定义。关系模型几乎不包含关于以下问题的线索：a)它们是如何创建的；b)数据间的各种关系实际上是什么；或者c)关系如何反映在模型中。多数用关系模型工业的从业者和专家因为其缺乏语义情境而动摇。因此许多专家，包括Ted Codd本人(CODD，E.F.，“Extending the DatabaseRelational Model to Capture More Meaning，ACM Transactions onDatabase Systems 4，4(Dec.，1979)，pp.397-434，以下称为[Cod79]”)尝试了创建语义数据模型(HULL，R.，KING，R.，“Semantic DatabaseModeling：Survey，Applications，and Research Issues”，ACMComputing Surveys，Vol.19.No.3，(Sep.，1987)pp.201-260，以下称为[Hull87])。例如，由Peter Chen于1976年提出的一种语义数据模型(CHEN，P.P.，“The Entity-Relationship Mode-Toward aUnified View of Data”，ACM Transactions on Database Systems 1，1(Mar.，1976)，pp.9-36，以下称为[Che76])几乎被全世界认可为确定关系模型的语义情境的手段。
已经有过许多认真尝试，试图将语义数据模型(SDM)实现为DBMS。没有一次尝试到达了商业市场，部分因为它们更难实现(仅仅是所要求的优化器就是困难的例题)，部分因为它们通常更难在实际的商业设置中使用。此外，DBMS捕捉的语义情境越多，它就越难做出校正和更改。虽然这些更改产生的影响可能比语义被功能性应用程序所管理时要小，但是在DBMS中有效地支持语义是非常困难的。使基于值或基于记录的DBMS运转起来花费的资源少得多。关于语义数据模型在商业市场上没有做得更好的原因的另一个观念是语义情境对增强性能做出的贡献不多(并且实际上还可能妨碍性能)。假如RDBMS由于性能受到了挑战，更多的语义情境尚未找到进入基于值的DBMS的途径可能也就不令人惊讶了。
除了极少数例外以外(例如，来自Lazy Software Ltd的Sentences)，语义数据模型没有被用作DBMS。与人类不同，计算机不必理解数据的语义情境。计算机只需要DBMS模式定义是高效的，以便维护和执行。如果语义情境帮助计算机更高效，则有了一个把语义信息包含在执行系统中的理由。没有理由相信语义情境会增强关系模型的性能。例如，没有RDBMS同样实现Peter Chen的E-R语义数据模型[Che76]。
有许多语义数据模型和专业实现技术，但是只有一种被广泛认可的实现企业数据库的手段-一种运行在关系模型上的RDBMS。
背景技术-关系模型：
Ted Codd的关系模型(于[Cod 70]中最初提出，并于[Cod79]中为当前情境定义)是关系DBMS的基础，而关系数据库是现今企业系统的普遍实施方式。在图1的“关系模型”所示的一个关系表示中，所有数据被折叠进二维关系(relations)(表(tables))中，它由属性(列(columns))和元组(行(rows))组成，以便属性值的某些组合可以唯一地标识每个元组(主键(primary key)或PK)。这样一个2D表被称为一个关系(因此就有了关系的(relational)这一术语)。一个关系中的其余属性(列)(即不是PK部分的属性)被称为关系的非键属性(non-key attributes)或NK。在每个关系内，当NK属性依赖并只依赖于指定的PK属性的整个集合时，即可确保完整性(规范化的(normalized)、范式(normal form)、第三范式(thirdnormal form)和3NF)。创建定义一个属性的可接受值范围的查找(lookup)关系确保了属性级别的完整性。
关系(表)只通过标识属性的共享组合彼此连接。PK属性在关系间迁移(migrate)，在这里它们被称为外键(foreign key，FK)。FK迁移从主(primary)关系开始，这种关系是PK中只有一个属性，没有FK。PK中有多个属性的关系被称为关联(associative)关系。从一个关系模型中提取信息通常是通过映射(projecting)和/或选择(selecting)，然后根据FK连接(joining)产生的关系，最后根据事务中指定的任何属性值限制过滤(filtering)结果表。结构化查询语言(Structured Query Language，SQL)可指定映射、选择、连接和过滤中涉及的数据操作。当以正确的(规范的(canonical)或规范化的(normalized)关系格式捕捉到了一个企业的数据库结构时，在储存的NK属性中就 没有冗余。关系模型的最佳定义可在[Cod79]第2节“关系模型”找到，它简洁地定义了哪种模型一般被认可为关系模型。该论文([Cod79])的剩余部分提出了一种扩展关系模型，以捕捉数据的更多含义。Codd的扩展关系模型寻求使关系模型向一个具有至少四个“个性”的更语义化的数据模型发展。该扩展关系模型未被工业采用。
关系模型的优点：
关系模型具有高度发展的结构，它促进了数据检索，以及NK属性的零数据冗余目标，它确保了数据完整性。关系模型还将逻辑数据表示与物理实现中分离开来。可用一个关系演算来定期操作数据库，其中关系演算是由一个高度发展并且广泛标准化的SQL来实现的，例如[SQL92]中所指定的SQL。
关系模型优点-面向应用的结构：
发展一个关系模型的过程使得数据模型确切地模拟商业模型。每个关系被创建来确切支持软件应用程序所要求的一定数量的终端用户的数据视图。一旦正确的关系元组位于关系模型中，特定用户视图所需的所有属性值(实例)就都直接包含在了元组的结构内。不需访问或检索更多的数据(除了有时需要查找储存在储存器中的值)。
关系模型优点-有限的数据冗余性：
关系模型的范式(normal form或canonical form)确保没有属性元组被储存多于一次。其优点是减少要储存的数据量并且确保可在无异常的情况下执行非键属性的更新。向一个RDBMS提出的每个问题应该只能以一种方式被回答(当一个数据模型中涉及多个复制的元组时，存在数据复本不同步的可能性，从而为问题提供错误的答案)。从平面文件模型中消除数据冗余性是关系模型的驱动特征之一。
关系模型优点-关系演算和SQL：
关系模型具有用于操作模型元素的高度发展的关系演算，以及具有用于不断操作关系数据结构的广泛标准化的SQL。
关系模型涉及的问题：
关系模型所涉及的的主要问题是其基本数据结构即是高度发展的又是取决于应用的。用最简单的话来说，一个关系的“行×列”结构缺乏对称性。绑定到各种关系中的属性、PK属性的名称和互联的FK的属性和结构对于一个特定的企业的操作就好像指纹对于一个人一样是唯一的。用SQL写成的关系应用软件完全依赖于关系和商业规则的结构。关系模型的每个方面映射到应用程序中的许多不同的视图/接口，并且软件应用程序中的每个视图/接口与关系模型的许多不同方面接口。应用软件和数据表示之间的这种多对多的关系的影响是使得应用程序和数据非常紧密地绑定在一起，以致于两者之中任一个有小的更改都可能对另一个产生重大后果。由于关系模型的取决于应用的数据结构(ADDS)是唯一、复杂和脆弱的(反抗更改的)，因此关系模型的ADDS特征引起了软件应用程序中的许多严重问题。
关系模型涉及的问题-ADDS与关系COTS：
ADDS使得商业现货(COTS)应用软件的发行和维护成为了非常困难的商业命题。由于每个应用程序本身是唯一的(由于ADDS的唯一性)，因此难以实现维持COTS应用程序的商业发布的规模经济。如果使数据模型更灵活(复杂)以兼容底层的商业模型的变化范围(例如一种产业内变化的操作实践)，此灵活性的人工产物会引起应用软件的复杂度成比例增加，以处理增强的操作灵活性(因为SQL紧密绑定到数据结构)。虽然任一特定实现只使用ADDS引起的灵活性的一小部分，但是每个实现必须能够完全标识并理解灵活性。关系方程-灵活性意味着不必要的复杂度-对于任何COTS软件的特定实现来说都是不可避免的。
建立在这种灵活关系模型数据结构上的关系应用程序常常要忍受操作困难和失败，这些操作困难和失败不是由特定企业的商业模型的任何方面引起的，而是由灵活性(包含在COTS应用程序中以兼容竞争者的商业模型)的不必要且没用到的人工产物引起的。
此外，标识、理解和忽略应用程序和数据模型中未用到的所引入的灵活性的人工产物必然会消耗企业中最有才能的IT人力资源，以及其他机构资源，例如储存、处理、培训和文档编制。由于COTS软件销售商的客户基础持续增长，对灵活性和随之而来的复杂度的需求增加，直到现有的客户基础开始拒绝COTS应用程序。这常常导致COTS应用程序销售商的失败。
称关系模型中固有的ADDS是COTS应用软件销售商的许多(如果不是大部分)商业失败的根本原因是有道理的，[即，a)商业生存能力要求巨大的灵活性，b)因为ADDS，巨大的灵活性意味着不必要的复杂性(对于任何特定的客户)，以及c)持续增长和不必要的复杂性引起客户停止使用应用程序。]
关系模型涉及的问题-长期冻结的基线：
对于一个特定的关系软件应用程序，在开始应用软件的编程之前必须知道/定义关系的完整结构。从而，由于ADDS，必须有长期冻结的需求基线，以便关系建模者可确定企业数据结构的详细说明并为其提供文档(具有复杂数据结构的企业要求按年测量的冻结的需求基线并不罕见)。复杂性如此之巨以致常常有必要用语义数据模型先以抽象词语先描述数据模型。由于企业的底层数据模型在冻结的基线期间确实会改变(有时还会很显著地改变)，关系应用软件通常落后于实际的企业模型，并且常常落后到了很大的程度。
关系模型涉及的问题-反抗更改：
由于ADDS以及与SQL的紧密绑定，关系软件应用程序对于关系结构中即使是最小的更改也是高度反抗的。此领域中最敏感的问题涉及主关系的单个PK属性的更改。一个主关系的任何特定PK可迁移以成为企业关系模型内的许多个关系的FK。这种PK属性的任何更改将引起整个关系模型以及相关的应用软件的更改。这意味着要做出小更改花费也是非常昂贵的，并且常常以花费昂贵的权宜之计来避免必要的更改(因为校正应用程序中的问题的花费更大)。作为ADDS和FK迁移的一个直接结果，关系应用程序的积压任务中通常有几年未应用的应用程序更改请求。这就是为什么基于关系模型的COTS企业应用程序对客户需求的适配度通常较低的原因。
关系模型涉及的问题-结构退化：
在典型的企业应用程序中，RDBMS面临着涉及信息的基本表格组织的物理重组问题。伴随ADDS的这个问题是关系信息是以高度组织化的形式的储存的，这种形式在储存介质中如果不是物理上相邻的也至少应该是群集的。但是，当一个表首次被加载(或重载)时，它只是以储存介质中的原始结构形式表示的。当行被删除和插入时，则不能维持磁盘上的这种群集的物理排列。随着时间的过去，由于关系模型对结构化数据储存的依赖，RDBMS的整体效率将逐渐损失很多。企业可以只是接受这种效率损失或者通过周期性地在物理储存介质上重组表来纠正它。
结构退化问题是关系数据管理中固有的。对复杂物理数据结构的依赖性是问题所在。所有复杂的物理数据储存结构都会随时间退化。当DBMS依赖物理结构进行组织时，处理效率以正比于物理结构腐蚀的程度退化。
关系模型涉及的问题-需要去规范化：
规范化被视为关系模型的一个关键理论力量。实际上它是该模型的重大弱点之一。关系模型的实现很少有能经受得住完全规范化中所涉及的低效率的。连接操作效率极低，并且规范化程度越高必须执行的连接越多。去规范化关系模型的结构提供了操作效率但是引起了更新异常以及大量的冗余数据，然后就必须定期操作这些冗余数据以支持操作。对于保持数据复本与记录复本同步更新的要求尤其是这样。所有这些复杂性都必须被添加到应用程序中。复杂查询要求如此多的连接以致关系模型上的数据库必须经常被进一步去规范化以便支持复杂查询。当更新处理器(OLTP)不能支持复杂查询所要求的增加的冗余性(去规范化)时，常常需要部署单独的DWH站点，仅为了支持复杂查询。
关系模型涉及的问题-元素安全：
企业应用程序的安全要求是难以预知的。客户常要求安全分级(对于数据访问)在行或列(属性)级别。在某些情况下，客户可要求安全性在表的“单元”级别(行×列)。在二维表结构的单元内实现安全标签是没有实用的方法的(当然没有有效的)。这是因为安全性实际上是二维表的一个不同的第三维。一个特定的“行-列”组合(二维)可能不要求安全性，或者要求一个或多个安全标签。如果正如关系模型所要求的那样，安全维被摺叠(折叠)到二维表上，结果并不好。
这是人工灵活性难以支持的一个领域的一个例子。为了使得应用程序广泛可用，底层的数据模型必须允许单元级别安全性。然而单元级别安全性可能只能在少数实例中调用。必须建立严格的关系表结构以处理所有实例(单元)上的安全标签。此方法非常低效的。另一个作为替换的可能是创建附属表结构(类别关系)，其中只有行-列值要求安全标签。在安全模式中，这使得处理事务所需的读取数量加倍。应用程序中存在的复杂性(例如安全性)维度越多，在二维关系描述中实现应用程序越困难。
关系模型涉及的问题-无法接口：
由于ADDS，在关系库中读取信息的能力实际上限于为之建库的应用程序。这是有讽刺意味的，因为Codd对于关系模型的原来意图[Cod70]是为了促进访问大型共享(shared)数据库。为了共享一个为/被其他应用程序建立的关系数据库并且有效使用其数据，软件应用程序必须学习“拥有”软件应用程序的复杂的ADDS。随着时间过去，当每个应用程序更改其商业模型以及其底层的ADDS时，其他所有必须共享应用程序数据的应用程序也必须同样地更改以便保持同步。由于此原因，在互联的关系应用程序的复杂的一面中即使做出一个小更改也可能就像向一池静水中扔下一块石头一样。更改的波动必须传播到全部互联的应用程序中。这对于关系应用程序的结构和构成有深远的影响。例如，多数关系软件应用程序不从其关系中消除不必要的属性。忽略这些不再必要的属性比起做出这种小更改并且忍受所有接口的应用程序的结构和构成上的广泛影响来说是更佳划算的。随着时间推移，关系实现中的不必要的数据结构和属性的持续存在可能在复杂性、储存空间和操作方面引起附加问题。
关系模型涉及的问题-无法模拟复杂的相互关系：
关系模型没有真正的模拟数据间的复杂的相互关系的机制。最基本的关系被封装在严格的属性集合中。其他所有关系只是“包含”在在关系间重复的FK内。因此，关系模型不以任何语义的形式定义关系间的关系。1976年，Peter Chen[Che76]定义了第一批语义数据模型中的一种(实体-关系或E-R模型)，以便扩展关系模型以解决此问题。为了定义和解释关系模型中PK和FK之间的关系，E-R模型添加了带有基数(例如，1∶1，1∶M，1∶0，1，M等)的命名“商业规则”(实体间的)的概念。在现实世界中关系模型和E-R模型如此普遍地混杂，以致大多数人以及实际上本领域的大多数专家都将它们看作同一种数据模型。在[Cod79]中，Ted Codd既纠正了这种概念，又尝试将关系模型扩展为一种语义数据模型，以包含关系间的复杂关系的定义和分类。
简而言之，关系模型提出了一种描述数据的手段(一种终止状态描述)以及一种添加-插入-删除和查询演算。关系模型不是一种理解、分析、定义、设计、描述或改进存在于数据间的复杂的相互关系的手段。为了做到这一点，通常要求一种语义数据模型，有很多种这样的语义数据模型可供选择(包括Chen的E-R模型[Che76])。
关系模型涉及的问题-OLTP与DWH：
当用关系模型实现大型或非常大型的数据库时，查询和更新事务之间的争用会引起严重的性能困境。对任务要求严格的企业应用一般要求实时应用更新。这被称为在线事务处理(OLTP)。但是，企业也需要查询数据库，并且所需要的许多查询是精细和/或复杂的。要在大型数据库中支持这种查询需要在SQL的“select”和“where”从句中提到的每一列上有第二索引。由于在更新过程中必须保持这些第二索引，因此他们向更新事务添加了相当大的开销。
假定连接表是耗时且耗资源的，复杂查询也能从减少必须访问的物理表的数目中受益。一种流行的方法是对表进行预连接(或去规范化)以减少连接的数目。虽然大多数OLTP站点确实在某种程度上对数据库进行了去规范化以改进性能，但是他们通常不能进行足够的去规范化以支持复杂查询。此外，随着去规范化和第二索引的数量增加，OLTP响应时间明显变坏。由于这种争用，已经越来越多地在单独的计算程序组上实现大型和非常大型的数据库的复杂查询支持，这种计算程序组被称为数据仓库。
优化OLTP安装以便最好地支持实时更新，同时仍支持足够的查询，以便实现日常企业操作的战术目标。优化DWH实施以便在大型和非常大型的数据库上支持无限制的复杂查询，并且其对更新过程不频繁的、最小的破坏符合战略评估和决策支持。OLTP支持最少量的数据库表列倒置(第二索引)，其最低程度上与战术要求一致。DWH支持最大(maximum)量的数据库表列倒置，这合理地促进了支持复杂询中的高效性。当前OLTP和DWH市场的方向是使这两种计算范例离得越来越远，而不是越来越近。
在数据库的同一拷贝上实现OLTP和DWH会有相当大的优势，如果解决方案有成本效益的话。例如，这样将简化培训、较低维护成本、改进数据的流通度和精确度，并且使战略支持成为许多目前不能同时承担一个OLTP和一个DWH解决方案的企业可企及的范围内。只是DBMS业将分离视为一件必要的坏事。
背景技术-语义数据模型：
正如上文所提到的，关系模型不提供模拟其关系内或关系间的复杂的相互关系的机制。正如出现在它之前的分级和网络数据模型一样，关系模型被称为“基于值(value-based)”或“基于记录(record-based)”的模型。语义模型最初是作为理解、分析、定义、设计、描述和改进数据相互关系的工具被引入的。可以在一个语义工具中模拟复杂数据模式，然后将其翻译成关系模型，以便在一个RDBMS上实现。
最先发表的语义数据模型，语义二元数据模型(SBDM)，出现在1974年(ABRIAL，J.R.，Data Semantics，Data Base Management，North Holland，Amsterdam，(1974)pp.1-59，以下称为[Abr74])。1976年，Peter Chen发表了所有语义数据模型中在商业上最成功的语义数据模型，E-R模型[Che76]，以解决关系模型中语义情境完全缺乏的问题。E-R数据模型在扩展关系模型上是如此成功，以至于当今许多数据库从业者将关系模型和E-R模型视为同一种模型。实际上他们不是。关系模型是由一个RDBMS实现的，而E-R模型是在一个实体-关系图表中实现的。由E-R模型引入的“商业规则”本身并不被RDBMS所支持。E-R模型的成功(与Codd本人以及其他人开发的更鲁棒的语义模型相比)根源于其简单性。
与本发明相关的、包含一个知识操作系统或KnOS的一个语义数据模型群组将数据描述为两种构造：实体集合和二元关系。这些语义二元数据模型(例如，[Abr74]，BRACCHI，G.，PAOLINI，P.，和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.，和PAULUS，W.，Relational model for a DataBase，Proceedings of the IFIP Congress，(1974)pp.1022-1025，以下称为[DHP74]，HAINAUT，J.L.，和LECHARLIER，B.，An ExtensibleSemantic Model of Database and its Data Language，Proceedings ofthe 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])将每个二元关系视为可能多值的函数一个反函数对(参见图6“语义二元数据模型”)。SBDM和本发明具有相同的核心构造(可能多值的函数的反函数对中的二元关系集合)，但是本发明本质上不是语义数据模型，因为它不企图定义关系。相反，本发明将二元关系视为基本的、未命名的“关联”，与关系模型实施E-R模型的净结果的方式很相似。
简而言之，人们渴望语义情境，计算机和DBMS不渴望。DBMS只从高效性和可维护性中受益。如果包含语义情境使得DBMS效率降低或者数据库/应用程序的可维护性降低，那么它被添加进DBMS的希望就比较微弱。不幸地，语义数据模型两者兼有(效率较低并且可维护性较低)。DBMS捕捉的语义情境越多，当发现有错误或企业模型更改时需要的更改就越多。如果不是这样的话，所有的商业RDBMS至少都把E-R语义数据模型[Che76]同化进了其基本框架中。
语义数据模型的优点：
语义模型的一种较好的处理由Richard Hull和Roger King于1987年提出，“Semantic Database Modeling：Survey，Applicationsand Research Issues”[Hull87]。语义数据建模技术与诸如关系模型这样的基于记录或基于值的模型相比提供了三个主要的优点。
概念和物理成分的增强的分离。在关系模型中，终端用户可用的访问路径倾向于直接模仿数据库模式的逻辑结构(通过比较标识符以便从一个关系遍历到另一个)。语义模型的属性被用作直接概念指针。关系类型的降低的语义过载。关系模型只有两种记录对象间关系的构造：a)通过在关系内绑定属性以及b)通过在两个或多个关系内使用相同的值。正是由于后一种原因，关系模型才常被称为“基于值”的。
方便的抽象机制的可用性。语义模型提供了以不同的抽象级别查看和访问模式的多种方便的机制。Peter Chen的实体-关系(E-R)模型[Che76]是被最广泛使用和认可的语义数据模型。E-R模型是理解、分析、定义、设计、描述和改进一个关系模型的标准语义数据模型。
语义数据模型涉及的问题：
语义数据模型被广泛用于模式设计中，但是作为实现计算解决方案的一种手段并没有取得很大的商业成功。关于这一点有几个原因。
大多数语义数据模型都不是实施模型(它们是用于模式设计的)。例如，E-R模型不是实施模型。
许多语义数据模型是被面向对象(OO)的行为计算范例所使用的。由于许多企业数据模型不支持包含广泛的明确的边界条件(OO的核心要求)，因此OO未能获得成功。
许多语义数据模型的兴趣焦点较窄，这一点不是很适合商业化为实现模型。
许多语义数据模型太复杂以致无法赢得广泛应用。Codd本人对关系模型的语义扩展[Cod79]由于其理论复杂性没有赢得追随者。非常简单的E-R模型是定义关系模型的标准语义数据模型。
关系模型固有的简单性允许开发强大的、非过程化的查询语言，例如ANSI SQL。许多语义数据模型可以被映射到一个用于实施的关系模型，从而利用关系建模的一般计算特征。因此，许多语义数据模型通过一个RDBMS被实施在关系模型上。
目前没有专家意见建议语义数据模型将会取代用于实施的、基于记录的数据模型(关系、网络、分级)。但是，很可能语义数据模型将会始终在模式分析和设计领域占有一席之地。
发明内容
本发明被称为知识操作系统或KnOS，并且是一种新的数据库管理计算框架，它按照与人类思考相同的方式关联地工作。KnOS的基本组织方案是一个RDBMS的反转，或者<数据值->关系>。这给予了KnOS单元(cellular)粒度，并且使其能够以最高效率回答任何种类的查询。KnOS不尝试根据企业模型中的关系储存数据，因此，KnOS的物理储存结构是独立于应用程序，并且在企业的关系更改时无需更改。此外，在处理数据时，KnOS不使用不对称的ASCII值，而是使用完全对称的矢量键引用。
KnOS设计解决了基于记录的(关系、分级、网络)DBMS所涉及的问题，如上所述。KnOS发明的意图是代替和取代当前一代的关系、分级、网络DBMS，或者任何其它当前实现的数据模型，包括OLTP和DWH。
本发明大体上将通过以一台或多台计算机使用软件的方法来实现。如图28所示，本发明可以用计算机硬件和软件实现。在图28的实施例中，输入和输出被显示进入KnOS处理器。然后处理器操作与本发明相符合的数据和指令。在图28的实施例中，数据既可储存在计算机本身的储存器中，也可以储存在外部储存器中。虽然目前更宁愿将本发明实现在一个处理器上，但在一个计算环境中的一台或多台计算机上利用系统也在本发明的范围之内，其中计算环境中包括由互联网或其他网络系统链接起来的计算机。对于某些特定应用程序，可能希望用软件、硬件处理器和固件来利用本发明。图29显示了一个固件设备，它具有三个功能，具体包括安全性、许可密钥管理和集储功能。其他利用固件的实施例可以在固件部分实现其他功能。在这种固件/硬件/软件系统中，在通过固件实现其他功能的同时可以向具有相关软件的KnOS处理器分配特定功能。在某些实施例中，固件和处理器都可以在不同的应用程序中向一个或多个储存设备读取和写入数据。虽然图29在固件框图中显示了三种目前首选的功能，但是要理解其他实施例可以具有本发明的固件处理的不同方面的内容。
为了清楚起见可能应用以下术语：
应用程序(Application)：用于执行一个特定功能的一个完全独立的程序
数据实例(Data Instance)：任何可辨的数据、信息或知识段。例如，用户可分辨的任何数据、信息或知识段，例如任何属性、项目、定子、键、表、列、行、域、容器、仓库、环境、类、类型、模型、函数、方法、操作、关系、显示元素、查询、数据模型、视图、报告、用户显示屏、数据类型、文件类型、项目路径、文件名、计算机名、UPC码、URL、用户、连接、状态、质量、分类器、字、句、段、页、章、卷、对象、分区、扇区或引用。
原子的(Atomic)：根据定义在不破坏其基本性质的情况下是不可分割的。
基本数据结构(Fundamental Data Structure)：一个数据储存或数据表示范例的最小结构成分。
项目(Item)：基于基本数据结构的KnOS数据库的基本单元，项目封装了一个自引用的矢量键、一个数据实例以及引用其他相关项目的多个矢量键集合。
矢量键(Vector Key)：对一个项目的一个多维的、唯一引用
矢量键集合(Vector Key Set)：矢量键的一个阵列，封装在一个项目内，它表示引用项目与矢量键集合中的矢量键所引用的所有项目之间的一种特定类型的关联。
逻辑地址(Logical Address)：一个项目的抽象位置，独立于其实际的物理位置。
逻辑索引(Logical Index)：直接引用与一个项目的实际物理位置相对的抽象位置的一个标识或值。
KnOS的某些方面表面上可能类似现有的数据管理范例和技术，但是KnOS设计是数据管理的一个全新的发明。KnOS是一种完全对称的计算框架-包括其所有的值、关系、结构和容器-并且所有KnOS都是在这些对称的特征上执行的简单的布尔函数。有了形式和功能上的100％对称，KnOS可以作为一种天生的大规模并行的矢量机来操作。KnOS根据在KnOS实施间普遍认可的一种格式使用单元粒度的矢量化的值表示。这意味着独立生成的功能应用程序可以在没有预先(priori)协议或结构/模式知识的情况下交换信息。有了完全反转的设计和最小限度的结构争用，KnOS可以以任何计算规模使用与最好的DWH产品相比更固有的处理效率，在单个数据拷贝上运行实时更新和复杂查询。因为KnOS的核心构造是二元关联式结构，因此它被称为一个关联数据库管理系统，或ADBMS。
本发明的关键区分因素是它是基于一个以数据实例中心结构的，其中数据实例通常是原子的，即根据定义从用户观点来看是不可分的，例如一个数据库中的一个表中的一个域中的数据，其中每个数据实例处于其所有关联的中心，并且封装数据实例和公共的基本数据结构的基本结构在形式和功能上是相同的，是独立于应用程序的，并且也包含被封装的、对其他所有直接相关的独立被封装的数据实例的引用。被封装的引用是每个和全部关联的数据实例的唯一标识符，并且也是完全编码每个数据实例的抽象位置的逻辑索引，它使得用相同引用键标识和定位任何数据实例成为可能。
对于数据实例，封装实体被称为一个“项目”。一个项目封装一个数据实例，以及定义该数据实例和其他所有相关的数据实例之间的关联的所有引用。项目是基于基本数据结构的，并且由一个矢量键标识，它是唯一标识KnOS系统中的每个项目的一个多维引用。
KnOS是第一个完全对称的企业计算范例，如图27“KnOS对称性”所示。对于KnOS，每个值与其他每个值看起来是完全相同的，每个关系与其他每个关系看起来是完全相同的，每个结构与其他每个结构看起来是完全相同的。计算模型中的这种基本对称性，当与单元粒度相结合时，允许多个处理器轻而易举地细分工作量，并且以并行委付执行操作。例如，KnOS不具有也不要求相当的关系“连接”操作。KnOS用完全矢量化的对称的结构上的最优二元树(或其等价物)搜索来进行所有处理。单元粒度、基本对称性和矢量表示的普遍使用可以将处理器效率最大化至其理论极限。除了其他方面以外，这还意味着处理器性能的改进会产生KnOS性能的成比例的改进。任何RDBMS或任何DWH应用程序都不是这样的。
值对称性-无论何时将任何原子数据值(即一个数据实例，例如“White Beans”、“$9.85”、“5”...)首次插入KnOS ADBMS时，都用一个矢量形式的全局唯一的、对称的引用值注册它，这个值被称为“矢量键”。在其首选实施例中，KnOS矢量键具有其中包含的四个位置维度。它们被称为环境( Environment)、仓库( Repository)、情境( Contexts)和项目( Item)，在这里将被表示为{E，R，C，I}。如果“White Beans”(一个数据实例)被插入到“全球”环境域的“MahattanSouth”仓库的“库存”情境中，则在KnOS中“White Beans”可能以矢量键{E，R，C，I}＝{0，6，1，3}来注册。矢量键可以被表示为四个维度唯一的32比特二进制整数的一个对称集合，每个集合是四个字的相异块。此16字节的矢量键是KnOS的每个项目的全局唯一标识符。除了提供唯一、对称、紧凑的值表示外，KnOS矢量键还可用于定位信息。封装了数据实例“White Beans”的项目{0，6，1，3}，可以作为计算环境#0中的第6仓库中的第1情境的第3个项目被找到。所有被管理的数据在首次加载时都按照这种方式被注册。KnOS ADBMS对任何ASCII值的进一步引用或使用都只引用这些代理矢量键。此设计特征建立了KnOS的值对称性(value symmetry)，如图23“值对称性”所示。
关系对称性-所有关系都作为一个或多个二元片断被记录在KnOS中，其中每个片段是两个项目之间的一个固有双向的关联。KnOS环境缺省地自动保持所述对的双向完整性。如果项目A指向项目B，则项目B总是指向项目A。KnOS关联本质上不是被命名的，而是基于值的，并且可以对它们分类以提高效率(语义分类是一种KnOS调整技术)。无论何时当KnOS项目经历语义过载并且应用程序能够区分关联的情境，则KnOS将按照情境储存各种关联。这减少了标识正确的关联所需的I/O，改进了性能。使用二元关联的双向对来储存和取回关系是完全对称的。图24“关系对称性”，显示如果由矢量键{0，6，1，3}所标识的“库存”项目“White Beans”与由矢量键{0，6，2，3}标识的一个“价格”项目“$13.45”相关联，则“库存”和“价格”之间的关系是固有对称的(如“’$13.45’is-price-of“White Beans’”所示)。注意表示为关系模型中的一个元组的相同关联只有当“库存”表的“价格”列具有一个第二索引时才是对称的。此外， 所有KnOS关系在关联内和关联间都被表示为对称的，而关系模型中的关系既以元组表示 又以外键或FK表示，它在表示内 和表示间都是非对称的。
结构对称性-二元关联的每个双向对的目标矢量键被储存完全封装其主体数据实例。如果“White Beans”(主体)has-price-of(关系)“$13.45”(目标)，则存有目标美元数量的项目在KnOS中可注册为{E，R，C，I}＝{0，6，2，3}。主体项目{0，6，1，3}(“White Beans”)可以用目标项目{0，6，2，3}(用于$13.45)封装，反之亦然。这种每个项目的被封装的引用的按类型分类的集合被储存在有序的一维阵列中，称为按照情境类型的矢量键集合(VK集合)，如图25“结构对称性-KnOS项目”所示。每个项目具有同样的完全对称的数据库结构-a)一个自引用(矢量键)，b)一个数据实例，c)关系(表示为VK集合)以及d)(可选)一个或多个项目内嵌元素(IEE)。带有其所有被封装的目标引用的KnOS项目结构同样按照类型分类并且储存在分类后的情境中，例如，“库存”在一个情境中，而“价格”在另一个情境中，如图26“结构对称性-KnOS情境”所示。每个情境与其他每个KnOS情境的构造相同，这意味着KnOS情境是完全的。与现有技术的系统相比KnOS系统有许多优点。下文将概括这些区别和优点。
下文略述了本发明的某些实施例的某些优点和目标。
COTS应用程序：因为KnOS项目是单元的，并且KnOS情境既是完全独立的又是100％对称的，因此KnOS数据库是不依赖于应用的。此独立性在可能存在的最广的范围内都是成立的。一个企业的资源计划应用程序的KnOS模式可能与，例如，一个地理信息系统具有相同的格式和结构。可以在不影响其他任何情境的结构、并且对软件不产生任何不可预知的或级联的影响的情况下包含或不包含一个KnOS情境。不论要实现哪种类型的应用，储存、访问和处理一个KnOS数据库的方式都是完全相同的。可以只用本地的可以获得的最佳知识一次一个情境地建立应用程序。一旦定义情境以后，可以在扩展情境时更新每个情境，不会改变其结构。可以为一个行业模型(或多个行业模型)准备COTS软件应用程序，然后在没有与RDBMS相关联的COTS应用程序问题的情况下在逐个案例的基础上实现。
没有冻结的需求基线：可以用任何快速应用程序开发或连接应用程序开发技术逐个项目、逐个情境以及逐个仓库地实现KnOS。由于KnOS设计，开发者不需要理解值的格式、关系的性质、一个数据库的总体结构或者甚至应用程序设计就可以开始开发和交付软件。KnOS的100％对称的单元化的技术不需要为了开发冻结需求基线。
不反抗变化：与实现时不需要冻结基线需求相一致，KnOS的灵活、增长的性质意味着可以为了本地变化持续调整应用程序，不会影响本地情况之外的任何东西。例如，可以在应用程序运行的同时无影响地添加或删除表的列的等价物。
不需要结构重组：KnOS的底层数据仓库不是按照随时间退化的表结构被组织的。KnOS内的插入、编辑和删除活动对于KnOS操作的效率没有影响。一个KnOS情境内的项目本质上是不依赖于序列或群集的；KnOS矢量键是绝对的，而不是依赖于序列的。因此，决不需要重载或重组织一个KnOS实施来提高效率。
能够完全规范化：完全规范化是数据库管理的一种非常精良的手段，因为除了其他优点以外，它还消除了更新异常和同步误差，同时减少了必须更新和维护的数据量。相反地，关系模型的性能与规范化的程度成反比地退化。结构规范化程度越高，RDBMS的性能越差。相反，KnOS设计中的完美的对称性意味着性能与规范化程度成正比。一个KnOS ADBMS实施在完全规范化时性能最佳。
此外，关系模型的范式只以或者非常低或者非常高的基数消除了非键属性中的值冗余性。表结构(基于值的关系)尽管更规范化，没有消除值冗余性。ASCII格式的PK值在整个关系模型中重复，因为基于值的外键被用于记录关系。
维度独立性-元素安全：KnOS从其单元粒度中继承了完全的维度独立性。一个表单元的KnOS等价物可以具有零个、一个或许多个值(0、1、M个基数)。KnOS数据模型是n-维的，这意味着可以用最适合需求的任何方式原地模拟应用程序的任何棘手的维度，例如元素安全性。
应用程序之间的接口：因为KnOS情境在粒度上是单元化的，并且是完全对称的，因此可以在不同实施之间比较其相似性，不论不同实施是否就不同关系的结构预先达成了协议。要使两个KnOS应用程序实现接口，只需要用相同的有关信息交叉引用情境。然后KnOS可在每个参与的应用程序或站点处维护这些情境交叉引用。只要应用程序发布一个违反这些情境交叉引用的事务，KnOS会自动转换任何矢量键、发布与目标站点相反的事务，然后在接收到响应时转换响应。通过这种方式，KnOS应用程序可以在不具有关于一个目标站点的ADDS的任何预先知识的情况下读取数据。有了KnOS，一个目标应用程序或站点的属性不会被约束在复杂的关系中以致于为了访问和理解列信息情境必须理解整个ADDS的复杂性。
能够模拟复杂的相互关系：KnOS与关系模型相比充分改进了关系情境。虽然KnOS仍然是一种基于值的数据模型，但是却可以用语义二元数据模型对其进行1∶1映射(参见图24“关系对称性”)。虽然每个关联不是特别命名的，但是可以就维度对KnOS中的二元关联进行完全分类，并且可以分离这些二元关联到从属于基本情境的独立的、被命名的标签集合。经验表明KnOS的四个(4)被封装的关联维度(“父亲”、“子”、“链接”和“相关”)首选实施例为实现任何给定的性能效率级别提供了充分的语义情境。KnOS的这些特征使得它能够利用语义情境来改进整体性能。
虽然不是首选实施例，但是可以在不损失SBDM中包含的任何语义的情况下很容易地扩展KnOS以支持一个语义二元数据模型。KnOS对于关系分类提供了两种广泛的选择-封装(encapsulation)和分割(segmentation)。被封装的关系位于项目的情境内(因此被叫做“被封装的”。分割的关系位于独立的、从属的标签集合情境内(项目对项目地匹配于基本情境)。在两种类别中，关系都可以被命名。标签集合是被命名的，因此采用标签集合没有任何语义情境损失。根据某种精确的语义情境，维度封装可以是一个被命名的分类，只要加上更多的关联“维度”即可。
OLTP和DWH范例的分辨率：通过将计算范例从表级别转换到单元级别，KnOS消除了许多关系模型中固有的争用。KnOS使用了“行”和“列”构造的封装效率，而没有表的任何破坏性非对称特征。因此，KnOS具有表表示的定位能力，没有表的非对称结构的任何破坏性的、依赖于应用程序的特征。KnOS赢得与完全规范化相关的效率和精确度，而没有与关系连接相关的任何低效率。由于KnOS本身是完全反转的(关系对称的)，因此它可以在单个计算范例和数据库拷贝上支持OLTP和复杂查询。KnOS重新结合了OLTP和DWH，带有所有的相关优势。
引用完整性的分辨率：交叉引用的基于表的数据是关系模型中的一个巨大挑战，并且随着它的发展需要持续增加越来越多的人造键和表以管理一个系统的复杂性。更新具有复制的键的复杂的非对称系统通常导致了由于更新的非完整性而引起的不一致，因为没有对于任何特定键的所有实例的直接引用。
以下是对KnOS的值、关系和结构表示的对称框架的简短说明，此对称框架克服了与关系模型相关的这些和那些问题。在这一节里始终引用的图22至26涉及图1中“关系模型”找到的例子。
还有另外的优点与KnOS相关。例如，KnOS所采用的开放磁盘格式的固有安全度与理论上可能存在的安全度相同。这是因为a)大多数数据库值是代理；以及b)没有由物理邻近所暗示的关联。KnOS磁盘格式完全是由被空格或ASCII比特式样周期性中断的二进制整数串组成的。可以通过用任何持续的ASCII数据实例和任何内嵌的ASCII值上的128比特加密运行KnOS来轻易地伪装ASCII比特式样，并且可以在性能惩罚最小的情况下完成这一点。一旦实现了这一点，则一个KnOS磁盘上数据对于除了应用程序本身以外的其他任何东西本质上都是无法被解密的。如果像首选实施例中那样，在应用程序中而不是数据库中维护一个数据库的精确语义情境，则用替代语义装载的情境分类(即VK集合被分类，但每个VK集合的确切语义情境并未记录在数据库中)消除了从KnOS的未经加工的数据格式中辨识出内容的任何可能存在微小的机会，有了在ASCII表示上的128比特加密，KnOS数据的盘上格式对于任何实际用途都是“一袋比特(bag-of-bits)”。
KnOS并不企图取代或扩展任何语义数据模型。相反，KnOS提供了一种在情境上与二元数据模型相似的更灵活的关联计算框架，以实现任何和所有企业数据模型。此外，它最大限度地利用语义情境(分类)以便在任何给定的企业模型上实现尽可能好的整体效率。就是说在KnOS中捕捉超过其首选实施例的额外的语义将可能增加计算的整体成本以及降低固有的安全性。
KnOS尝试用一种更广泛关联的DBMS来整体取代RDBMS。“关联”一词旨在描述这一事实：KnOS并不像关系模型中那样限于关系和FK实施例的集合结构，而是允许可由更强大的语义数据模型定义的关系情境的完整范围。有了单元粒度以及形式和功能的100％对称性，KnOS设计是数据库管理中的一个新的基准，一种应该取代当前所有基于值的计算范例的单元计算范例。
附图说明
图1是一个现有技术关系数据模型的图示。
图2是关于如何将一个关系模型中的一个主关系同化到KnOS中的图。
图3是关于如何将一个关系模型中的一个关联关系同化到KnOS中的图。
图4是显示如何将来自图1的一个主关系和一个关联关系的行和列同化到KnOS情境中的图。
图5是显示来自图1所示的例子中的关系模型的所有关系的同化的图。
图6显示了被描绘为一个语义二元数据模型的来自图1的关系模型例子。
图7显示了如何将语义二元数据模型的单个片段同化到KnOS情境中。
图8是将图1所示的关系模型显示成一个语义二元数据模型和一个KnOS模型的图。
图9是显示为什么KnOS情境构造是独立于应用程序的图。
图10是将KnOS操作与图1所示的等价的关系操作相比较的图。
图11是显示KnOS集储操作的一个例子的图。
图12是显示一个四维引用模型的图。
图13是显示一个KnOS项目的结构的图示。
图14显示了KnOS的对称引用。
图15是显示KnOS ASCII表如何将ASCII值转换成与它们等价的KnOS矢量键的过程模型。
图16是显示根据项目的矢量键取出一个项目的六个步骤的图示。
图17是表示为一个仓库的基本数据结构的图示。
图18是表示为一个情境和一个项目的基本数据结构的图示。
图19显示了在一个物理介质上更新KnOS项目的一种方法的一个实施例。
图20显示了在一个物理介质上更新KnOS项目的一种方法的另一个实施例。
图21显示了KnOS的结构以证明KnOS的可缩放性。
图22描绘了环境之间的相互引用。
图23显示了ASCII和KnOS值表示之间的比较。
图24显示了关系、语义二元和KnOS数据模型之间的对称性(或对对称性的缺乏)。
图25显示了一个KnOS项目的结构对称性。
图26描绘了KnOS情境的结构对称性。
图27描绘了KnOS设计的对称性。
图28显示了结合了KnOS的一个典型计算环境的框图。
图29描绘了利用固件的一个实施例。
图30显示了现有技术。
附图详述
以下是对每幅图的详细说明和对各幅图的详细解释。图1“关系模型”显示了一个主关系(“库存”)，其单一主键(PK)属性为“库存”，以及一个关联关系(“库存定单”)，其PK是两个外键(FK)属性的组合，即来自“库存”关系的“库存”和来自“定单”关系的定单号。图1还显示关系如何投射、选择和连接以回答样例查询-“所有库存定单中的white bean价格是多少？”。
图2，“同化一个’主’关系”，显示了如何将关系模型中的一个主关系同化到KnOS中。“库存”主关系的元组被命名为“Pinto Beans”、“Kidney Beans”、“White Beans”和“Wax Beans”。“库存”情境是用于记录行关系的一个KnOS情境的例子。一个主关系的所有其他列按每个KnOS情境一列的方式被同化，在此例中，一个“库存”情境和一个“价格”情境(列状情境)。
图3“同化一个关联关系”，显示了图2中所示的过程，但是是用于一个关联关系的，或者是用于关系的PK作为来自其他关系的一个FK迁移进来的关系的。对于每一个关系列有一个KnOS情境，再加上表示库存定单关系的元组的KnOS情境。
图4，“将行和列投射到KnOS情境”描绘了将“关系”从图1转换到KnOS情境的第一步。为一个关联关系(“库存定单”的行创建一个KnOS情境，并且为两个关系的每一列创建一个KnOS情境，产生了“库存”、“价格”、“定单”和“数量”的附加的KnOS情境。
图5，“将关系同化为KnOS情境”显示了将图1所示的关系模型例的所有关系同化入一个KnOS模型。
图6“语义二元数据模型”显示了图1所示的关系模型的经典语义二元数据模型。它与KnOS的相似之处在于对于语义二元数据模型的每个节点有一个KnOS情境。每个双向关系被命名并且关联的实例(即多值)被显示在左上部。
图7“将二元关联表示为KnOS情境”显示了图6所示的语义二元数据模型的单个片段如何。该例显示了“库存”实体和“价格”实体之间的关系。关系的每个元素用来自“价格”实体的匹配值关联“库存”实体的一个值(例如“Pinto Beans”)。语义二元数据模型描述是非对称的，而KnOS描述是对称的。
图8“对数据表示的比较”显示了所有三个表示-关系模型、语义二元数据模型和KnOS-中描述的来自图1的关系模型例的原始数据。底端是来自关系模型的ADDS。左侧是表示为一个语义二元数据模型的相同的数据库。右上部是同样的原始数据的KnOS表示(虽然VK集合中没有描述精确的情境)。KnOS情境既可以表示来自一个二元数据结构的数据也可以表示来自一个表结构的数据。
图9“应用程序独立性”显示了为什么KnOS情境是独立于应用程序的。向“库存”关系添加一个新属性(新的一列)将改变关系模型中“库存”实体的物理构造。有了KnOS情境数据结构，同样的改变只不过是向“库存”情境添加更多VK集合，它不会改变项目或情境的结构。在添加“数量”属性关联前后项目具有相同的结构，即{矢量键-数据实例-VK集合}。
图10“KnOS操作”显示了KnOS如何用“被引用的取出”进行核心操作。此例是形成在图1的关系模型上的同一问题。KnOS将会：
(1)确定哪个库存定单是关于white beans的。从“库存”容器中取出项目{0，6，1，3}(数据实例＝“White Beans”)。(2)从项目{0，6，1，3}中提取对“库存定单”容器的任何VK集合引用(即{0，6，3，X}形式的矢量键)，即{0，6，3，1}&{0，6，3，5}。(3)确定相关数量。从“库存定单”容器中取出项目{0，6，3，1}&{0，6，3，5}，并且提取对于“数量”容器的任何VK集合引用({0，6，5，X})。答案分别是{0，6，5，1}&{0，6，5，3}。从“数量”容器中分别取出{0，6，5，1}&{0，6，5，3}以便获得答案(数据实例)“1”和“3”。
(4)确定white beans的价格。从项目{0，6，1，3}(数据实例＝“White Beans”中提取对“价格”容器的VK集合引用(即{0，6，2，X}形式的矢量键)，即{0，6，2，3}。从“价格”容器中取出项目{0，6，2，3}以获得答案(数据实例)“$13.45”。(5)对KnOS结果进行扩展和求和以获得$53.80。取出项目{E，R，C，I}是一种被引用的取出，因为矢量键{E，R，C，I}既是一个唯一引用又是一个KnOS逻辑地址。
图11“集储的一个例子”显示了KnOS将如何回答问题“‘PintoBeans’的那些库存定单的数量＜＝2？”。在“集储”操作中，从数据库中取出相关项目，并且将其放在一个“集储场”中，以便进行一系列直接整数比较，其目的是确定交点。第一步是从“数量”情境中取出数据实例＜＝2的所有项目，并且将它们放在“集储场”中。接下来，从“库存”情境中取出数据实例＝“Pinto Beans”的项目，并且将其放在“集储场”中。在{E，R，C，I}(此例中为{0，6，3，X})的前3个成分上执行一个直接整数比较。根据整数比较产生的交点，{0，6，3，2}或库存定单2*，就是问题的答案。
图12“多维引用模型”显示了如何将一个给定的多维矢量键“{1，38，1，5}”指定到现实世界的情形。在本发明的首选实施例中，多维引用模型具有4个维度。可以将世界视图或环境指定为国家，如“美国”＝#1所示。可以将仓库视图指定为国家内的处理站点，正如“NewYork处理站点”＝#38(在环境#1内)所示。可以将个人的标识指定为{E，R}＝{1，38}内的情境#1。可以将“Duane Nystrom”这个人指定为{E，R，C}＝{1，38，1}中的引用#5。“Duane Nystrom”的唯一多维引用，或矢量键，将是{1，38，1，5}。它也是用于查找“Duane Nystrom”的抽象位置的逻辑索引；哪个环境中的哪个仓库中的哪个情境中的哪个项目(详尽细节请参见图16)。
图13“一个项目的结构”显示了一个实际项目的概念和物理表示。物理表示被描绘在右侧。项目是可变数目个字(每个字＝32比特或4字节)，这里显示为每行4个字的行。列是为了便于读取VK集合-第一列是环境(“E”)维，第二列是仓库维(“R”)，第三列是情境(“C”)维，最后一列表示项目维或项目(“I”)。这里将此矢量键缩写为“(E，R，C，I)”。
图14，“双向引用”显示了KnOS的一个基本属性。每个显式引用具有一个显式的反向引用。这里显示了“Duane Nystrom”的头发颜色为“Brown”这一引用。头发颜色情境中的“Brown”项目也包含一个反回“Duane Nystrom”的显式引用。该图还显示了从“Duane Nystrom”到一个电话号码的一个内嵌引用。对于内嵌引用，没有反向引用能力。
图15，“ASCII-betical转换”显示了如何将一个数据实例“DuaneLewellyn Nystrom，Esq”转换为其KnOS矢量键。在一个ASCII表中查找第一和第二字母以确定哪个项目的数据实例值以“Du”开头。然后用个人情境{1，38，1，0}集储所得的项目。这产生了两个符合的项目的一个交点。比较所有符合的项目上的数据实例值以获得答案{1，38，1，5}。
图16“在物理介质上定位项目{0，6，8，2}”显示了KnOS如何利用矢量键({E，R，C，I})的值定位项目。首先，KnOS从仓库容器中取出“C”值匹配特定的{E，R，C，I}的{C，R，N，O}目录条目(一种矢量键格式)。在此情况下，{E，R，C，I}＝{0，6，8，2}匹配仓库目录条目{C，R，N，O}＝{8，3，1，5}，这给出了情境{0，6，8，0}在磁盘上的位置。接下来，KnOS从{0，6，8，0}情境中取出“I”值匹配特定的{E，R，C，I}的{I，R，N，O}目录条目(一种矢量键格式)。在此例中，{E，R，C，I}＝{0，6，8，2}匹配情境目录条目{I，R，N，O}＝{2，3，6，7}，这给出了项目{0，6，8，2}在磁盘上的位置。
图17“仓库结构”是表示为一个仓库数据结构的基本数据结构的图示。
图18“情境和项目结构”是表示为情境和项目数据结构的基本数据结构的图示。
图19“在物理介质上更新项目{0，6，8，2}-I”显示了更新后的项目在更新后不符合其先前的空间分配的情况下可采用的一种KnOS更新方法。更新后的项目附在仓库文件末尾。
图20“在物理介质上更新项目{0，6，8，2}-II”与图19类似，只不过它描绘了在KnOS下的物理磁盘管理的首选实施例。如图18所示，项目{0，6，8，2}接收一次更新，使得它大于当前磁盘上分配的1页。在首选实施例中，KnOS没有空间注册。相反，KnOS首先将把下一容器，在此例中为{0，6，5，223}，移动到文件末尾，从而释放出足够的空间，以便将项目{0，6，8，2}返回到其原位置。实际上，项目{0，6，8，2}继承了先前分配给{0，6，5，223}的空间作为额外空间。
图21“KnOS可缩放性”描述了如何将一个典型的高端站点配置为一套由一条高速总线互连的松散耦合的处理节点。
图22“计算环境之间的相互引用”描述了在KnOS中结合多维矢量键如何使得能够跨计算环境边界地关联完全断开的数据系统中的项目。
图23“值对称性”显示了如何将非对称的ASCII表示转换为对称的KnOS引用。
图24“关系对称性”显示了关系、语义二元和KnOS数据模型的对称性或对对称性的缺乏。
图25“结构对称性-KnOS项目”描述了如何将一个本质上非对称的关系模型描述为对称的KnOS项目。
图26“结构对称性-KnOS情境”描述了在对称KnOS情境中如何分组和封装KnOS项目。
图27“KnOS对称性-KnOS情境”描述了KnOS设计的整体对称性-值、关系和结构。
图28-显示一台计算机上实现的KnOS系统的框图，其中KnOS软件在系统上操作。
图29-显示了一台计算机上实现的KnOS系统的框图，其中KnOS软件在系统上操作，该系统利用了结合数据安全性、许可密钥管理和KnOS操作加速器的固件。
图30-图30是一个现有技术的数据库系统的图示。它在一幅图示中显示了关于单个库存定单的库存、数量和定单关联。可以看出关系格式和关联格式中的数据模型的相对紧凑性。
具体实施方式
图28和29显示了一个计算环境。虽然可以用多种方式包括在多台处理器上实现系统，图28显示了一台计算机上的一个软件实施例。图29是显示在一台计算机上实现的KnOS系统的框图，其中KnOS软件在系统上操作，该系统利用了结合了数据安全性、许可密钥管理和KnOS操作加速器的固件。虽然只显示了这两个实施例，但本领域技术熟练者将充分理解利用不同硬件配置的许多种实施例都可使用本发明。因此本说明书通过引用结合了2002年7月26日提交的美国申请序列号60/398,843和2003年3月25日提交的60/457,207。
为了解决先前概括的关系模型中固有的问题，按相反于关系模型的结构构造了KnOS。在KnOS中，数据值导致关系。KnOS的组织规则是<数据值->关系>，这意味着KnOS是一种完全相反的数据模型。KnOS通过类型分类在被连续封装的情境中储存原子数据实例，并且在每个数据实例的储存机制中，KnOS以矢量键格式存储对与该数据实例相关的所有关联的引用。在KnOS术语中，一个相同的情境中被封装的数据实例值被称为“项目”。情境通过仓库被封装，而仓库通过环境被封装。数据实例之间的所有关系无论如何复杂，都被分割成两个项目之间的二元关联。然后通过将关联组织到VK集合中并且在相关联的项目内封装它们来按照语义或其他概念情境对关联进行类型分类。简而言之，环境的被封装的成员是仓库，仓库的被封装的成员是情境，情境的被封装的成员是项目，而项目的被封装的成员是与其他项目的关联的分类集合，它们被表示为矢量键(VK)并且按照语义或其他情境分类成VK集合。这种基本组织使得KnOS能够有效地将数据值关联到关系。
粒度：
数据模型是如何组织的(即是<关系->数据值>还是<数据值->关系>)也决定了数据模型的粒度(granularity)。粒度是一个数据模型包含可被独立访问的成分的程度。可被独立访问的成分越多，则粒度越大。粒度越大，数据模型越灵活。
一个数据模型的粒度不能被独立建立。这是完全根据主组织规则(即<主体->对象的主体来确定的。如果模型是按照规则<关系->数据值>组织的，则数据模型的粒度是一个关系(主体)的最小元素。对于关系模型，关系的最小元素是关系元组(即一个关系的一个实例，一张表的一行)。否则，模型是按照相反规则<数据值->关系>组织的，数据模型的粒度是一个数据值的最小元素。数据值类似于关系模型中的每个唯一的非空单元值。由于此原因，将相对于关系模型反转的模型，例如KnOS，描述为具有单元粒度，而关系模型具有行级别粒度。
KnOS将一张关系表中的一个单元值的每个唯一实例视为一个独立的概念，称为一个项目。由于KnOS项目是KnOS设计的基础，因此它意味着KnOS能够在单元级别表示关系数据。KnOS被适当刻画为具有单元粒度(cellular granularity)。换句话说，与按行读写信息的关系模型不同，KnOS按照每个指定情境内的唯一单元值读写信息。
每个KnOS项目内封装了对于其他所有关联的概念(项目)的特定引用，包含该特定行中的所有单元值，以及表中具有该特定的单元值的其他所有单元，以及这些行中的所有关联的概念等等。这满足了组织规则<数据值->关系>，因为当向KnOS提供一个数据值或数据值的一个描述时，KnOS的组织规则可以提供与这些数据值关联的所有关系。简而言之，KnOS是以数据实例为中心的，而关系模型是以关系为中心的。
总而言之，关系模型的粒度是元组(tuple)(一张表的行)。如果你能够向一个关系模型标识一个元组，则它能够向你返回与该元组相关联的或者包含在该元组内的所有数据值。KnOS的粒度是一个给定情境的每个唯一的数据值，即每个唯一的可辨别的概念或项目是原子的。如果可以向KnOS模型标识单个唯一的数据值(项目)，则它可以返回与该项目直接关联的所有项目。
将KnOS与关系模型相比较可能是方便的。实际上，任何关系模型可以完全被同化到一个KnOS表示中，其方法是首先对其进行完全规范化，然后根据其行×列方向将表内的所有唯一的数据值分类为二元关系。但是，反过来就不正确了。虽然总是能以一个KnOS模型来表示一个关系模型数据库，但是并非总是能够以一个关系模型来表示一个KnOS数据库。同样的陈述对于与KnOS相比较的分级模型和网络模型也是正确的。KnOS与任何基于记录集合或表的数据模型相比，是一种灵活得多的数据建模范例。可以建立完全不能关系地表示的KnOS企业模型。
因此，虽然以相对于关系模型地方式来考虑KnOS可能是很方便的，但是以这种限制的方式来定义它对于KnOS发明造成了伤害。与关系模型不同，可以以用户可辨别的任何抽象级别来定义KnOS中的项目。例如，任何数据实例，即任何可辨别的数据信息或知识段，可以是一个KnOS项目。它可以是一个特征、定子、键、表、列、行、类、类型、模型、程序、函数、方法、操作、显示元素、图像、查询、数据模型、视图、报告、用户显示屏、数据类型、文件类型、项目路径、文件名称、表名称、计算机名称、数据库、UPC码、序列号、部件号、URL、用户、协议、连接、消息、状态、质量、分类器、字、句、段、页、章、卷、对象、分区、扇区、BLOB、CLOB、指针或引用。一个KnOS项目可以是用户可标识(辨别)的任何东西，任何概念。
简而言之，KnOS是一种无限制的n-维建模环境，而关系模型是一种折叠的2-维表示。如果用户只喜欢关系表示，则KnOS可以很容易地适应用户。对于一个KnOS数据模型的粒度的决策留给了实现者。KnOS对于如何组织数据没有任何预想的维度概念。在其首选实施例中，KnOS是一种完全自引用的建模环境，这意味着与实现相关的所有东西都作为适当类型的KnOS项目被储存在KnOS数据库中。
对称性
在对于本发明的详细说明的整个过程中，正文都将谈到对称性，这意味着a)双边对称性，b)形式和排列的对称性以及c)部件的大小、形状和位置的一致。
本说明书不会详细说明为什么对称性是建模过程的一个重要特征。说模型越对称则它定义、变化、处理起来就越简单高效就足够了。模型对称性对于处理中的并行性也是很关键的。模型越对称，则它越容易被并行处理，并且越能被完全地并行处理。关系模型通过分析对称性来寻求关系的定义。一旦已知，则按照其对称性完全分类关系。随后被确定具有相同对称性的任何候选的不同的关系被合并成为相同的关系。然后剩余的唯一的非对称定义的关系以范式构成了关系模型。从而，非对称表示被用作关系模型中定义的主要方式。当通过范式适当构成时，关系模型是100％非对称的。除了其他方面以外，这还意味在构造数据模型之前必须正确理解所有企业关系。如果关系模型的两个不同的成分后来被确定为是对称的或者结构上全等的，意味着被包含在表中的同一列，则必须校正数据模型以合并这两个成分。
KnOS模型不是基于关系的，而是基于唯一的数据值的。KnOS关系被定义为由被封装为项目并且表示为多维矢量键的两个数据实例之间的二元关联片段组成。KnOS被明确设计为第一个由对称的值、关系和结构组成的完全对称的计算范例。对KnOS对称性的讨论将从值对称性开始。
值对称性
ASCII值是完全非对称的，因为它们缺乏a)双边对称性；b)形式和排列的对称性；以及c)大小、形状和位置的一致性。所有数据值、概念等(KnOS项目)中绝大多数被表示为ASCII值，主要例外是二元大型对象(BLOB)。当以ASCII格式表示数据值时，由于许多原因数据值难以储存和处理。因此，许多数据仓库DWH应用程序替代ASCII值的位图表示以尝试向计算过程注入对称性和紧凑性。DWH在本地化的基础上利用位图，而KnOS在普遍范围内具有完全的值对称性。
KnOS通过将每个项目的ASCII值表示(这里称为数据实例或ThOhT)转换成一个完全对称的多维引用(这里称为一个矢量键)来将100％值对称值注入到计算范例中。在将每个单独的项目首次引入到一个KnOS计算环境中时，向它分配它自己的唯一的矢量键，并且以后在任何其他情境中永不改变、更改或重新使用该矢量键分配。KnOS矢量键是每个数据实例的一个完全对称的代理。换句话说，当将一个KnOS矢量键与另一个相比较时，此行为具有a)双边对称性；b)形式和排列的相似性；以及c)大小、形状和位置的一致性。此对称性被描绘在图23“值对称性”中。
无论何时在KnOS中开始任何操作(更新或查询)，第一步总是确定作为参数出现在事务中的任何数据实例的矢量键。如果提供给KnOS的任何数据实例是新的，则KnOS或者拒绝操作(如果是一个查询操作)，或者(如果是一个更新操作)a)向新的数据实例分配一个唯一的矢量键，并且b)将新的数据实例添加到其ASCII表字典。然后KnOS的数据实例矢量键被KnOS专用于计算操作。实际上，KnOS在前门处翻译非对称的数据值，并且以后只用完全对称的矢量键作为代理来工作。
KnOS的对称引用采取一个矢量键的形式，该矢量键由模型的每一维度中唯一的二进制整数的一个有序集合组成。在本发明的一个典型实施例中，矢量键具有四(4)个维度，称为环境( Environment)、仓库( Repository)、情境( Context)和项目( Item)。在这里通常称为{E，R，C，I}的KnOS矢量键的每一个是由四个不同的三十二比特(一个字，四字节)的二进制整数组成的，其中每个二进制整数在该维度上是唯一的。任何特定应用的实际引用维度数目可以少于或多于四个。四个维度只不过是首选实现方式。在某些实施例中，只将一个32比特字中的30比特用作矢量键，留下2比特来标记系统限定的引用类型，但是对于需要的实施例完全比特宽度是可用的。字宽是由计算环境定义的；因此，如果一个64比特的字宽可用，则引用可以是64比特的。矢量键不限于项目引用。矢量键适用于具有相同的{E，R，C，I}格式的容器标题：环境标题＝{E，0，0，0}，仓库标题＝{E，R，0，0}，情境标题＝{E，R，C，0}，并且也适用于仓库目录({E，R，N，O}格式的)和情境目录({I，R，N，O}格式的)。VK集合(矢量键阵列)必须按照类型统一-{E，R，C，I}格式中的矢量键不能与{I，R，N，O}格式中的矢量键相混。
关系对称性
在关系模型中，关系以两种方式之一被记录：基本关系或共享标识符值(FK)。这两种方法是完全不同的，并且完全缺乏对称性。按照定义没有两个关系或共享的标识符值是相同的。如果两个关系或两个共享的标识符是相同的，则它们被合并成一个。关系模型的记录关系的方法实际上就其独特性而自豪，这就是说它缺乏对称性。
由于KnOS的基本组织规则(<数据值->关系>)相对于关系模型是反转的，因此KnOS要求 所有关系比较两个且只有两个数据实例。KnOS将这些二元关系称为关联。从 任何数据值到伴随的关系的组织要求意味着所有二元关联本质上是双向的(反转的)。图24“关系对称性”所示的例子显示两个数据实例，项目＝“White Beans”和项目＝“$13.45”彼此关联。特定语义情境是a)“WhiteBeans”have-price-of“$13.45”(“White Beans”的价格是“$13.45”)和b)“$13.45”is-price-of“White Beans”(“$13.45”是“White Beans”的价格)。在假设其基本组织规则(<数据值->关系>)的情况下KnOS必须能够访问任意一种语义情境。
无论从关联内还是关联间来看，KnOS的二元双向关联都是100％对称的。当KnOS在两个项目之间注册一个双向关联时，该关联具a)双边对称性，b)形式和排列的对称性，以及c)大小、形状和位置的一致性。
这里值得对图24所示的例子的语义情境作一个简短评估。关系模型和KnOS都不会用这么多字(即have-price-of和is-price-of)来记录两个精确的语义情境。每个模型只记录“价格”在某种程度上被包括在关系中。关系模型将“价格”作为列名称(属性)记录，而KnOS将“价格”作为情境名称记录。图24左上部所示的语义二元数据模型确实直接记录了每个关系的整个语义情境。KnOS通过类型相似性映射关系的语义情境，从而可通过读取其维度的情境和封装情境内的关联来直接推断语义情境。
结构对称性
一个数据模型中最后和最重要的对称维度是结构对称性。结构对称性涉及如何储存模型的部件。关系模型的组织规则<关系->数据值>意味着数据是按照关系被储存的。关系模型中描述关系的方式是非对称的，因此数据储存的结构是非对称的。因为KnOS的组织规则是由数据值驱动的(<数据值->关系>)，因此KnOS具有结构对称性。
实际上，KnOS储存结构中的每个不同的抽象级别都是对称的，如图25“结构对称性-KnOS项目”和图26“结构对称性-KnOS情境”所示。作为VK集合被封装在项目容器内的关系具有结构对称性。每个项目在结构上与其他所有项目都是相同的。项目被按类型分类并储存在情境中。项目的每个情境与项目的其他所有情境在结构上是相同的。实际上，KnOS在容器类型间是结构对称的，即使不同类型的KnOS容器执行不同的功能。项目容器和被称为情境的KnOS容器是结构对称的。同样的结构对称性也存在于仓库容器和环境容器中。
图27“KnOS对称性”显示了不论如何看KnOS模型，它都是完全对称的。不论考虑值、关系或结构，这一点都是正确的。
在KnOS模型的结构对称性内，还存在着包容的对称性。在其他所有DBMS中，数据值不引用其容器，因为它们只是占据空间，并且拥有一个容器中的一个位置。一旦从一个容器(即一个表或一棵树)中读出，数据值就不引用其容器，从而必须在外部维护情境。随着数据实例读取数目增长这变得越来越困难。作为KnOS项目中的所有数据实例与它们的容器(情境)具有对称关系，因为项目本质上是通过其矢量键自引用的，从而指向其本身，从而按照定义引用了其容器(情境)。情境始终引用其“内”的项目。此外，将项目从逻辑到物理映射到其实际位置是对称的，因为KnOS维护着从实际位置到位于该处的项目的一个物理到逻辑映射。
矢量键：
矢量键具有两个不同的用途。第一个用途是充当标识每个和全部项目的一个唯一的标识符。第二个用途是充当一个定位键或者逻辑索引，以允许KnOS查找一个项目。将一个矢量键用作对任何项目的通用引用使得KnOS能够将被顺序封装的容器引用(正如首选实施例中{E＜R＜C＜I}那样的)编码为键元素，并且将这些元素用作对每个被顺序封装的容器的直接索引。由于矢量键既作为每个项目的一个标识符，也作为每个项目的一个定位器，因此它被直接用于指定被封装在一个项目中的关联的任何维度的任何VK集合的一个关联。
在本说明书中始终使用的“维度”一词涉及两个不同的方面-a)项目的引用的维度；以及b)项目的关系的维度。矢量键本质上是对于它们在项目的引用维度内的唯一位置的一个逻辑索引。因为矢量键也唯一标识项目，因此它们也用于在项目间记录关系。从而，当矢量键被分类成一个项目的引用的VK集合的一个维度或另一个维度时，它们被用于唯一标识和直接定位相关联的项目。KnOS关联的分类构成关系维。
KnOS被称为被维度折叠的(dimensionally enfolded)，或者被顺序封装的。项目被保存在一系列清楚分界的容器中，以便每个项目在其父亲容器或封装容器中被唯一编号。一个项目容器可以在其父亲情境中被逻辑定位。项目的一个情境可以在其仓库容器中被逻辑定位，而项目的一个仓库可以在其环境容器中被逻辑定位。只用一个矢量键就可以在维度之间传递直到定位到一个特定的项目。每个项目容器封装其关系维度。
在本发明的首选实施例中，二元关联或关系也按照四(4)个维度被分类-“父亲”、“孩子”、“链接”或“相关”-并且被封装在每个项目容器内，其中每个维度中的关联的二元状态分别由其存在或不存在一个引用相关联的项目的矢量键来表示。矢量键的存在唯一标识了该维度中的每个相关联的项目，并且向KnOS提供了直接定位它的手段。从而关系维度被折叠到项目维度内。
每个环境总是其自身的第一引用。一旦进入一个指定环境则暴露出了所有折叠的项目维度。参见图22“计算环境之间的互相引用”。在一个典型实施例中，每个环境具有3个主要的折叠的项目维度(R、C和I)，以及一个主要的外部维度(E)，其中E＝1通常是对该环境的自引用。(E＝0通常引用“创建者”或“许可证主”)，并且在遇到另外的环境时添加这些环境。通过这种方式，每个环境具有对可能不同的其他环境的“E”引用。
这里重要的是要注意“E”是一个逻辑引用，从而可以想象一个环境值，比如“2”，能够涉及不同KnOS环境中的不同东西。换句话说，不存在带有关于哪个“E”是哪个的特定分配的主环境列表，因此必须由某个权力机构维护列表。这并不妨碍分配规定的一套普遍可引用的“E”。例如E＝0可以是KnOS的中央许可权力机构。E＝411可以是KnOS系统的主知识库。E＝611可以用于维护或技术支持等。实际上KnOS可保留最初的“n”个“E”，用于这类型的应用。
每个项目具有四(4)个主折叠维度({E，R，C，I})中的唯一的被封装的矢量键，因此可以通过用每个项目自身的矢量键分类和封装所有关联的项目来将每个环境中的每个项目关联到每个环境中的其他每个项目。每个环境的多维引用模式在内部是完全一致的，即一个环境内的任何项目的一个矢量键都是唯一的，不论该环境内的其他哪个项目将其用作一个引用。
理解矢量键并非特定存储器地址或特定物理位置指针这一点是很重要的。每个项目被放置在一个情境中，与其他每个可应用的项目相关联，但是所述放置是由引用完成的，而引用是被封装在情境内的并且不必是物理上相邻的。项目始终通过逻辑引用而不是地址或物理位置被储存和取出。因此，哪些基本机制被用于在一个储存介质中实际储存项目并不一定是很重要的，只要它们可适应KnOS的要求并且效率是最佳的就行了。这里描述了储存和取出项目的典型的基本机制。这里应该注意首选的储存机制在KnOS的逻辑和物理层之间具有对称性，即逻辑位置系统封装物理定位标记，而物理储存系统封装逻辑定位标记。
与任何项目相关联的KnOS数据实例与一个特定的情境中的一个关系属性的单个实例相似(例如，个人＝“Duane Nystrom”，数量＝“3”、库存＝“White Beans”，或者价格＝“$13.45”)。情境与一个关系属性的全部(例如，个人、数量、库存、价格)相似，包括其全部范围的值。换句话说，KnOS情境可保存一个特定类型的项目的所有项目。矢量键的仓库维是情境的一个集合。它可能是指一个现实世界的位置、一个特定的机器集合体或者其他任何取决于用户/应用的数据组织，例如地区、行政区或城市(例如，New York，NY或Los Angeles，CA仓库)。矢量键的环境维是仓库的集合，它可用于表示世界视图，比如国家或大陆(例如美国或加拿大环境)。特别地，它通常用于标识作为一个仓库集合的收藏场所或经纪的实际的现实世界计算环境。在实际应用中，具有四个维度的引用足以处理任何数据管理问题，尤其因为这些维度只涉及KnOS的项目维。关系模型的语义情境通过关联的分类和分割在KnOS中具有无限维度(以下将进一步说明)。
图12“多维引用模型”描绘了多维引用方案的一个典型实例。正如矢量键符号({E，R，C，I})所意指的，矢量键只是连接在一起的四个不同的、一个字长的二进制数字，例如{1，38，1，5}(环境#1、仓库#38、情境#1和项目#5)。在32比特机器上(4个字节为一个字)，矢量键的四个成分中的每一个通常被限制为一个30比特的二进制整数(即，230＝0-1,073,741,824以10为底)，(但是也可使用全部32比特)。因此整个矢量键可以引用或标识230×230×230×230＝2120个不同的项目。
多维引用模型是广泛可扩展的。首先可以是一个位置，然后添加上第二个、第三个等。然后可将位置分成多个环境。对于单个位置，{0，1，1，5}可以是一个有效的矢量键，是指唯一一个仓库的情境#1中的第五个项目。以后如果添加了第二个仓库，则它将成为仓库#2。对于第一仓库中的数据不需要做任何改变。来自一个环境/仓库的数据可被来自其他任何环境或仓库的应用程序读取，不会产生混淆。
KnOS项目：
KnOS项目是基于独立于应用的基本数据结构的。图13“一个KnOS项目的结构”显示了一个项目的一个概念表示和一个完全成形的物理表示。物理显示在右侧。由可变数目个字(在一台32比特机器上，每个字＝32比特或4字节)组成的一个项目在这里被显示为多行，每行4个字。
右侧所示的行×列表表示全然只是为了说明，并不表示一个项目的实际实现。18行×4列的结构实际上并不存在。图13所示的“DuaneLewellyn Nystrom，Esq.”没有18×4＝72个字，而是71个字。行6中灰化单元不存在。该项目实际上是一个长度可变的记录。图13所示的项目的行×列表示是为了便于读取项目自身的矢量键和相关联的项目的矢量键。当涉及到项目自身的矢量键或项目的VK集合时，字的四列表示矢量键的维度-{E，R，C，I}。否则四个列对于项目没有意义。
项目中的四个字的第一“行”是图13中的项目{1，38，1，5}的主自引用矢量键。由十二个字组成的第二、第三和第四“行”给出了项目的“地图”，描述了如何读取可变长度的项目的其余部分。图13中的项目地图指定项目的数据实例在接下来的7个字中，显示为“|Duan|eLe|well|yn N|ystr|om，|Esq.|”。
每个项目还连接和封装了相关联的项目的矢量键，以便每个项目完全封装与特定项目相关的所有被规定的关联的和(数据实例、数据值、概念)，这些矢量键的数目不受限制，它们是以分类的(分维的)集合的形式排列的，被称为矢量键集合。单个项目内的不同VK集合对应于关联的不同类型或分类，通常有四个主要类型。图13的项目地图显示首先是三个“父亲”矢量键(每个矢量键是四个字)的一个VK集合，然后是两个“孩子”矢量键的一个VK集合，然后是两个“链接”矢量键的一个VK集合，接着是两个“相关”矢量键的一个VK集合。“父亲”、“孩子”、“链接”和“相关”是KnOS使用的四种典型的关系(语义情境)分类或维度，它们可被看成表示语义情境“是”、“具有”、“做”和“涉及”。随时可添加任意数目个另外的语义情境，KnOS对此不作限制。
如果需要，可以在项目内嵌入额外的相关的元素。这些元素被称为项目内嵌元素，或“IEE”。IEE可以是数据，例如一个部件号码或者一个街道地址，或者是引用其他项目的VK集合。图13显示“Duane Lewellyn Nystrom，Esq.”项目具有一个内嵌的电话号码(“514-824-9949”)和街道地址(“3307 Blake Lane，Unit 47”)。也可以将内嵌的元素表示为单独的项目，并且通过主VK集合维之一、或通过在内嵌的元素中例示为单个矢量键或一个VK集合的一个第二维来明确引用。内嵌的项目数据是可选的。如果对一个关于个人的仓库提出的大多数查询也同时查询个人的电话号码，并且从未进行过按照电话号码的独立查询(即，谁的电话号码是“514-824-9949”？)，则将这些值嵌入到每个个人项目中是有意义的。否则，“电话号码”应该是凭其自身存在的一个情境。例如，如果仓库必须支持一个按照电话号码的查询，那么不对所有项目中包含的数据进行一次完整的搜索的话，嵌入电话号码就不会起作用(除非所有内嵌的项目也被添加到了一个ASCII表字典中(参见下一节)，并且被交叉引用，从而能够通过二元树搜索标识和访问)。
KnOS中的每类容器都是一个独立于应用的基本数据结构，因为它在结构上是全等的，自引用的，并且封装了它的内容，并且完全独立于任何用KnOS构造的应用程序。假定的KnOS容器的分类方案，从最低级别到最高级别排列为-项目、情境、仓库、环境。一个情境收藏若干数目个项目，一个仓库收藏若干数目个情境，而一个环境收藏若干数目个仓库。注意“情境”一词是指一种特定类型的容器，即逻辑上收藏所有根据某种情境定义或分类被分组的项目(即个人、客户、产品、公司、品种、颜色、部件号...)的容器。
KnOS情境和仓库：
图18的左半部分“情境和项目结构”显示了项目的一个情境。图18的右侧显示了这样包含的项目之一。从结构上来说项目和情境之间没有差别。项目具有成员，即矢量键的VK集合，情境具有附加的成员，即项目。
在一个情境中，一个项目成员的矢量键不是字面上的{E，R，C，I}，即使它具有同样的结构和相同数目的字元素。按照定义，一个情境的任何特定成员与同一情境的其他所有成员以及该情境本身具有相同的“E”、“R”和“C”值。从而一个情境的项目成员的矢量键中只需要保存项目(I)值，或者矢量键的四个成分中最右边那个。其他3个维度的规定(即“E”、“R”和“C”)被用于“物理定位器”索引、以字节为单位的项目大小以及情况和状态标记。所有成员的矢量键都可以被项目(I)值以分类的顺序保存，这一点使得能够在情境中迅速查找任何特定的项目。
情境中的这种成员信息使用也显示在图16“在物理介质上定位{0，6，8，2}”中。图16中的项目#3显示了情境。项目#4和#5显示了情境的成员(两对中的四个字)。在一个正常的{E，R，C，I}中，“I”将是第四个位置。由于在一个情境中不需要保存“E”、“R”和“C”，因此一个情境中的成员矢量键以最左侧位置的“I”开始。可能把这些{E，R，C，I}描述为{I，R，N，O}更好，表示项目、相对、下一个和偏置。当从左向右读时，情境中的成员条目给出了项目的实际号码，接下来是它在项目定位器目录中的相对位置(这涉及最后两个位置N和O)，接下来是磁盘上将会遇到的下一个项目的号码，接下来是项目的数据实例的页偏置。
对于仓库容器也存在类似的情况。在仓库的情况下，成员描述情境，这意味着矢量键最好被描述成{C，R，N，O}，意思是情境、相对、下一个和偏置。当从左向右读时，仓库中的成员条目给出了情境的实际号码，接下来是它在情境定位器目录中的相对位置(这涉及最后两个位置N和O)，接下来是在磁盘上会遇到的下一个情境的号码，接下来是情境的数据实例的页偏置。图17“仓库结构”描述了这一点。
图16显示了对于{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}， 都是矢量键，并且当它们被分组或分类时，都被称为VK集合。
这描述了KnOS的一个核心能力-只用项目的矢量键和内嵌在磁盘介质中的逻辑到物理目录就能定位项目。{C，R，N，O}格式的VK集合是磁盘仓库目录。{I，R，N，O}格式的VK集合是磁盘情境目录。KnOS可以通过将项目的{E，R，C，I}首先与它的情境的{C，R，N，O}相比较然后与它的仓库的{I，R，N，O}相比较来定位和取出任何项目。
一个项目的定位和取出过程中的第一步是定位出正确的环境。从环境中可访问{C，R，N，O}格式的仓库目录。利用仓库目录，KnOS将事务所引用的{E，R，C，I}(在此例中为{0，6， 8，2})与{C，R，N，O}相比较。{C，R，N，O}＝{ 8，3，1，5}是匹配{0，6， 8，2}的仓库成员条目(即{E，R， C，I}中的“C”与{ C，R，N，O}中的“C”值匹配)。在此例中，仓库目录条目中的为“5”的“O”值给出了磁盘介质上包含有关情境的页的偏置。
利用情境目录，KnOS将事务所引用的{E，R，C， I}(在此例中为{0，6，8， 2})与{I，R，N，O}相比较。{I，R，N，O}＝{ 2，3，6，7}是匹配{0，6，8， 2}的情境成员条目(即{E，R，C， I}中的“I”与{ I，R，N，O}中的“I”值匹配)。在此例中，情境目录中的为“7”的“O”值给出了磁盘介质上包含有关项目的页的偏置。
图17和18描述了一种替换的访问方法，它根据物理到逻辑“目录”分割上述逻辑到物理“目录”的元素。磁盘位置的物理到逻辑“目录”位于各仓库容器的VK集合中，RAM位置的物理到逻辑“目录”位于KnOS自身的环境容器中。统一的是RAM和磁盘定位器的页标识符偏置引用，这消除了对单独的操作系统存储器和磁盘管理子系统的需要。按照页标识符的所有存储器分配和去分配都由KnOS管理。只有物理层读写才由硬件驱动器处理，其中硬件驱动器翻译页标识符偏置，并且将它们映射到RAM和磁盘系统的基本物理结构。
情境名称和项目数据实例：
所有KnOS情境都具有一个描述或分类情境中的项目的内容的名称。类似的，一个情境中的每个项目表示一个特定的情境中的一个唯一的数据实例，从它是表示用户如何标识一个情境 内的每个项目的意义上来看，它可以被想象成一个名称(name)。由于它们是用于标识，因此情境的名称和由一个情境中的每个项目所表示的数据实例值应该是唯一的。许多情境和被封装的项目可以由用户唯一命名，但是有的不行。
解释KnOS关于被命名的和未被命名的的概念的最简单的方法是把它与关系模型相比较。当一个规范化的数据表(3NF)被KnOS同化时，表的每一列被映射到一个KnOS情境。然后KnOS在每个情境内创建一个被封装的项目，其名称＝列中的每个唯一的、非空的单元值，对应于KnOS中的一个数据实例。此操作将表的每一列中找到的每个唯一的数据值同化成了KnOS项目。如果“颜色”是表中的一列，则“颜色”将是一个KnOS情境的名称(属性或列)，并且各种颜色本身-粉色、绿色、淡紫色-将是“颜色”情境内引用的项目(即“绿色”将是“颜色”情境中的一个特定项目的数据实例)。如果“年龄”是一个情境(属性或列)，则归于年龄的基数(1，2，3...n)将是年龄的数据实例(即“14”是一个年龄数据实例)。列中的每个唯一的数据实例(即每个离散的ASCII值)是一个“数据实例”，并且每个数据实例与一个具有一个矢量键引用的项目相关联。在图13“一个KnOS项目的结构”的例子中，数据实例＝“Duane Lewellyn Nystrom，Esq.”。
如果在一个3NF表中的两个不同的列中遇到了颜色“棕色”，则它将被视为两个不同的数据实例，并且两个不同的项目将被创建出来-每列中的一个“棕色”项目。两列可能具有两个不同的名称，例如“头发颜色”和“眼睛颜色”，它们将是关系的两个不同的语义情境。注意“棕色”可以在两个不同且独立的情境中与一个个人相关联-独立地做为某个人的头发颜色和某个人的眼睛颜色。KnOS可以类似地将这一点实现为单独的情境-一个被命名为“头发颜色”，一个被命名为“眼睛颜色”，而“棕色”将是每个情境中的一个项目的数据实例。到目前为止创建出的情境可以被视为列状情境。为了记录KnOS中的行关联，我们还需要一个KnOS情境来表示行。如果用户能够命名一个3NF表中的行值，则该表通常是一个主关系，以一个属性(列)作为表的PK。在这种情况下，表示表的PK的 一个KnOS情境是表的行代理。
如果关系模型中的一个主表具有一个用作PK的单列，则它被命名为表。PK列的值唯一标识了表的每一行，或者关系的元组。当一个主表被KnOS同化时，表的PK列成为KnOS中的行代理情境。如图2“同化一个主关系”所示，“库存”主关系具有两列-“库存”和“价格”。这两列将被同化进KnOS中，作为被命名为“库存”和“价格”的两个情境。由于“库存”是表的PK，或者行的唯一标识符，因此KnOS中的“库存”情境自动成为一个行状情境。它在构造上与其他任何何KnOS容器都没有不同，但是它的项目表示被同化的表的行-一个KnOS项目用于库存表中的一行。
相反地，“价格”情境可能对于价格列中的每个唯一的、非空的单元值具有一个项目。如果“$9.99”在表的价格列中出现252次，则KnOS将只有一个“$9.99”的“价格”项目。
这描述了被命名的情况-作为一个唯一PK的带有一个单列的一个主关系。如果表是一个不同种类的主关系，比如一个“个人”表，并且个人名称不是唯一的，则有必要有其他单列来作为PK，例如一个社会安全号码或员工号码。
无论何时当要求两列或多列作为一个3NF表的PK时，都将表称为关系模型中的一个关联的关系，意思时它关联了两个或多个表，每个表是3NF形式的。这些关系是FK关系。图3“同化一个’关联’关系”显示了一个关联关系，其元组不能被用户命名。此库存-订单表关联了两个主关系-库存和订单。库存-订单表的PK是库存+订单。不太可能任何用户都会知道关系的每个元组的这种组合，尤其如果存在数千个“库存”项目和数千个“订单”项目。“库存”和“订单”(关联关系的元组)之间的关联组合可能太大以至于无法记住每行的名称。
例如可能不会期望有人会记住“库存”项目“Pinto Beans”是与“订单”项目“1111”相关联的。在这种情况下，用户可能请求显示与“订单”项目“1111”相关联的所有“库存”项目，然后从显示出的项目中挑选出所需的“库存”项目。或者反之亦然，用户可能请求显示与“库存”项目“Pinto Beans”相关联的所有“订单”项目，然后从显示的项目中挑选出所需要的“订单”项目。
如果在一个3NF表中没有像一个关联关系中那样有单个名称列，则表的代理的一个单独的KnOS情境必须被例示到KnOS中。这个特殊的行状情境的名称很可能将是关系表的名称。这一点被描述在图3“同化一个’关联’关系”中。“库存-订单”关系的“库存”、“订单”和“数量”列被同化到列状情境中，正如上面的主关系那样，然后库存-订单表作为一个名称代理被同化到一个“库存-订单”情境中。注意此行状情境的KnOS项目没有真实的名称，只有人工名称(1*、2*、3*...n*)。这是它为什么被称为一个未被命名的关系的原因。
一旦已经标识了同化的行状KnOS情境，则为每行的每个列值的引用建立一个二元关联。这一点被描述在图5“将关系同化到KnOS情境”中。有两个行状容器，一个是用于库存订单关联关系的，一个是用于库存主关系的，分别是情境“3”和“1”。
内嵌在关系模型的主关系中的行关系被记录在“库存”和“价格”情境中，在“价格”情况下作为每行的每个非键属性列中的项目之间的二元关联，在“库存”情况下作为PK KnOS情境的每列中的项目之间的二元关联。这是通过只使用为每列中的每个数据值创建的项目的矢量键来完成的，如图5所示。对于关联关系库存-订单的行完成同样的操作。
总而言之，如果关系模型中的一个元组具有带一个唯一名称(ID)的一列，则它被视为一个主或被命名的关系。当被同化到KnOS中时，一个被命名的关系将会对表的每一列转换到一个KnOS情境。包含元组名称的单列将会映射到一个KnOS情境，该KnOS情境将被视为表的行代理。如果关系模型的一个元组在其PK中具有多个属性或列，则它被视为一个关联的或未被命名的关系。对于一个未被命名的关系，KnOS将会创建一个人工情境，用作关系的代理。关系中的所有列的所有数据值将被逐行地从每个列情境关联到此人工(代理)名称情境。
关系的维度(语义情境)：
关联分类是KnOS的一个基本概念。在KnOS的典型实施例中，项目之间的所有关联被分类到四个自然类别中，它们对应于项目引用的四个缺省VK集合。四个关联分类在图13中被显示为“父亲”、“孩子”、“链接”和“相关”。以下对自然关联类型的说明用“猫”例为一个示例项目：
父亲：从项目B是项目A的“父亲”或“分类”的意义上来说项目“A”属于项目“B”。从一个孩子属于一个父亲的意义上来说主体项目属于目标项目或分类。如果主体项目是一只“猫”，则目标项目可以是，比如，“动物”、“猫科动物”或“宠物”。
孩子：从项目A拥有、生产或分类目标项目B的意义上来说，或者从一个父亲拥有一个孩子或多个孩子的意义上来说，项目“A”拥有项目“B”。例如，一只猫具有“毛皮”、“尖牙”和“爪子”。
链接：项目“A”做项目“B”，因为项目A从事、激活或负责做被引用的项目B。例如，猫“吃”、“打盹”和“瞄瞄叫”。
相关：项目“A”伴随项目“B”，因为类比或涉及条件以某种方式使项目A与项目B相关。例如，在我们的社会中，猫与“狗”、“老鼠”和“喧闹”相关(即“冷静”的猫和“hep”的猫)。这可能是关联链接的最弱的类别，但是它在广泛概念搜索中也可能极有用。此外，项目可以按照类比或相似被相关，例如单语言同义词或多语言名词等价。
分类对关联的项目的所有引用的优点主要在于，减少一个确定矢量键的交点的KnOS“集储”操作中必须匹配的矢量键的数目，通常该操作利用一个布尔AND操作。
例如，比方说一个医学实验室测试组织样本的抗菌易感性。这些测试的数据实例可能是未被命名的，因为测试是关系模型中的一个关联关系。实验室的计算机系统可能赋予每个这样的测试一个“人工”的名称，例如用于记帐。一个特定的测试的人工名称可能是“23A-3&44-2121222-Jason”，KnOS将会把给定的人工名称记录为每个测试项目的数据实例。但是，没有用户会知道、记住或识别出此数据实例，因此它在支持访问中没有价格。相反，一个试图定位测试数据实例＝“23A-3&44-2121222-Jason”的用户可能必须给出足够的线索才有希望接近标识它。例如，用户可能要求查看由“Jason Lee”在2002年7月12日运行的测试。由两条线索形成的该查询可能产生零个、一个或许多个可能的结果。当用户看到Jason在7月12日运行的所有测试时，他们可能能够认出正在寻找的那个。在此测试例子中，实验室技术人员可能执行测试，并且日期可能被分类成一个“父亲”链接。当寻找Jason Lee在2002年7月12日的测试时，KnOS只需要用2002年7月12日和Jason的“孩子”VK集合来“集储”测试项目的“父亲”矢量键来查找矢量键匹配。
实际中，从分类到关联类型的任何映射都是被KnOS所支持。以上列出的四种类型是为了进行说明，虽然对于人类记忆是基本的，但仅是对于如何考虑按情境分组关联的建议。
现在考虑关系维度的精确语义情境。关系模型的大多数从业者使用Peter Chen的实体-关系模型来设计模式和记录语义情境(商业规则)。在绝大多数情况下，商业规则将为“是”或“具有”。问题是语义情境实际上是否有帮助。考虑图8“对数据表示的比较”中所示的语义模型等价体。
--------<关联>---------
主体     目标           语义情境
价格     库存           Is-Price-of(是...的价格)
库存     价格           Has-Price-of(具有...的价格)
库存     库存-订单      Is-Ordered-On( 是在...上被订购的)
库存-订单库存           Is-For(是关于...的)
订单     库存-订单      Has-Stock-On(具有...上的库存)
库存-订单订单       Is-On(是在...上的)
数量     库存-订单  Is-Qty-of(是...的数量)
库存-订单数量       Has-Qty-of(具有...的数量)
在以上每个例子中，语义情境(商业规则)是“是”和“具有”与主体或目标值的组合。此例在关系模型的绝大多数现实世界实现中都是正确的，这就是为什么没有商业RDBMS从E-R模型实现语义情境的原因。此语义情境不是划分或分类关联的一个良好的候选者，这意味着它不能减少必须搜索的关联的矢量键的量，这意味着它对于一个DBMS的性能没有益处。但是，按照下面的方式重新限定语义情境可以产生显著的性能改进：
主体     目标            语义情境
价格     库存            Is-Price-of(是...的价格)
库存     价格            Has-Price-of(具有...的价格)
库存     库存-订单       Was-Ordered-On(是在...上被订购的)
库存-订单库存            Was-For(是关于...的)
订单     库存-订单       Relates to-Stock(涉及库存)
库存-订单订单            Relates to-Order(涉及订单)
数量     库存-订单       Is-Qty-of(是...的数量)
库存-订单数量            Has-Qty-of(具有...的数量)
字典系统和ASCII-表转换：
字典系统是一个独立的仓库，它保存ASCII-表的有序列表，该表中包含ASCII表的每个字符(1-255)，从而保存字母表的每个字母(大写和小写)、一位数(0，1，2，3，9)等的有序列表。有许多不同的实现一个KnOS字典系统的方法。对于可以添加的字典数目也没有理论限制。可以为每个科学或语言或一门语言中的短语添加一个新的ASCII-表字典。此外也可实现UniCode-表字典，以支持基于亚洲语言或其他复杂字符集的知识体。此外，可以创建字典以表达任何记号或符号集合，以及任何值集合。以下是一种类型的ASCII-表实现，它描述了结构的优点，但它不是想要限制可能的字典实现方法或技术的范围或多样性。
如图15“ASCII-betical转换”所示，确定当基于每个项目的数据实例的ASCII值的前两个字符时，对仓库#6的访问足够快。如果在任何时候证明该假设是错误的，则可检索项目的数据实例的更多字母。因此，两个字典情境被放置到环境#1、仓库#6(情境#1和#2)中。第一个情境被分配给仓库中的所有情境名称和项目数据实例的第一个字母；第二个情境被分配给所有情境名称和项目数据实例的所有的第二个字母。于是两个字典情境的多维引用将为{1，6，1，0}和{1，6，2，0}。每个字典情境将正好有255个项目。ASCII字符不需要被翻译为以10为基数的整数0-255，因为八比特ASCII字符可以作为从“00000000”到“11111111”的八比特二进制整数被自然读取。以10为基数的数字0-9是ASCII字符#48-#57。字母表的26个大写字母是ASCII字符#65-#90，而小写版本是#97-#122。“DuaneLewellyn Nystrom，Esq.”的前两个ASCII字符，即大写“D”和小写“u”，分别是ASCII字符68和117。
当数据实例为“Duane Lewellyn Nystrom，Esq.”的项目以矢量键{1，38，1，5}被添加到个人情境中时，项目的数据实例的前两个字母的矢量键也被添加到两个字典情境中的每一个。数据实例为“DuaneLewellyn Nystrom，Esq.”的项目的矢量键(即{1，38，1，5})将分别被添加到两个字典情境中的大写“D”({1，6，1，68})和小写“u”({1，6，2，117})孩子VK集合中。换句话说，项目{1，6，1，68}和{1，6，2，117}将 各自在它们的“孩子”矢量集合内包含矢量键{1，38，1，5}，项目{1，38，1，5}将在它的“父亲”VK集合中包含项目{1，6，1，68}和{1，6，2，117}的矢量键。
取出“Duane Lewellyn Nystrom，Esq.”的KnOS矢量键的第一步是分别从情境{1，6，1，0}和{1，6，2，0}中取出ASCII大写“D”{1，6，1，74}和ASCII小写“u”{1，6，2，117}的KnOS项目。来自许多不同的情境的许多项目将以ASCII字符大写“D”开始，来自许多不同情境的许多项目将以ASCII字符小写“u”作为它们的项目的数据实例的第二个字母。但是，少得多的项目会同时符合两个条件，更少的项目会属于个人情境{1，38，1，0}。
ASCII大写“D”和ASCII小写“u”的VK集合被放置到一个矢量集储场中，以目标情境{E，R，C，I}＝{1，38，1，0}作为控制。集储操作确定在两个VK集合中包含了{1，38，1，X}形式的哪个矢量键。以两个VK集合中较小的那一个中对应于{1，38，1，X}控制元素(在此例中为{1，38，1，5})的最低的矢量键元素开始，KnOS将对其他VK集合进行一次最优二叉树搜索，以查找一个匹配。如果找到一个匹配，如图所示，则该值将被移动到答案集储场中。此搜索将一直继续直到已经在目标VK集合中搜索了两个VK集合中较小的那个中的控制形式的所有元素。在图15所示的例子的，两个矢量键符合集储标准-{1，38，1，5}和{1，38，1，24}。
下一步是对于两个项目{1，38，1，5}和{1，38，1，24}中的每一个发布一个被引用的取出。这将返回两个项目，一个带有数据实例＝“Duane Lewellyn Nystrom，Esq.”，一个带有数据实例＝“Duane LeeGuy，Jr.”。在多个ASCII值上的一个简单的字符串比较将给出所需的结果，即“Duane Lewellyn Nystrom，Esq.”的全局矢量键是{1，38，1，5}。这完成了称为ASCII-betical转换的过程。
另一个字典实现的方法由一个情境中的单个ASCII编码的项目集合组成。对于具有一个由ASCII字符组成的数据实例的每个项目，使用一个或多个ASCII索引内嵌元素集合作为VK集合，表示第二和更多的字符实例出现。此方法与前一方法相比优点在于已经使第二、第三和更后的字符的关联按照作为第一字母之后出现的元素这一事实被过滤，从而集储操作只在第三和更后的字符上完成。
KnOS操作：
图10“KnOS操作”显示了与图1所示的关系模型操作相比KnOS如何进行核心操作的一个例子。回答的假设问题是-所有库存订单上的white beans的总价格是多少？关系模型通过以下步骤回答此问题(1)从“库存-订单”关系中投射“库存”和“数量”；(2)从“库存”关系中选择“White Beans”；然后(3)连接投射和选择。结果被扩展并求和，得到$53.80。
上述关系讨论排除了关于索引的讨论。对于KnOS，索引操作将包括根据在字典情境上执行的一个ASCII-betical转换确定“WhiteBeans”的矢量键，以及用库存容器对取出的项目的VK集合的一个“集储”。该过程被描述在图15“ASCII-betical转换”中，如上所述。一旦根据ASCII-betical索引操作确定了“White Beans”的矢量键{0，6，1，3}，KnOS将用被引用的取出回答相同的问题：
步骤#1-哪些库存订单是关于white beans的？从“库存”容器中取出具有数据实例＝“White Beans”的项目{0，6，1，3}。从项目{0，6，1，3}中提取对于“库存-订单”情境的任何VK集合引用-{0，6，3，X}形式的矢量键-即{0，6，3，1}&{0，6，3，5}。
步骤#2-相关联的数量是多少？从“库存-订单”情境中取出项目{0，6，3，1}&{0，6，3，5}，并且提取对于“数量”情境的任何VK集合引用，{0，6，5，X}。答案分别是{0，6，5，1}&{0，6，5，3}。从“数量”情境中取出{0，6，5，1}&{0，6，5，3}，以便分别得到具有数据实例“1”和“3”的项目。
步骤#3-white beans的价格是多少？(根据上述(1))从项目{0，6，1，3}中提取对于“价格”容器的VK集合引用-{0，6，2，X}形式的矢量键-即{0，6，2，3}。从“价格”容器中取出项目{0，6，2，3}以获得具有数据实例“$13.45”的项目。
KnOS结果被扩展并求和，以得到$53.80。取出项目{0，6，2，3}的步骤是一个被引用的取出，因为项目{0，6，2，3}既是一个引用，又是一个KnOS地址。
上述操作是通过直接查找所需要的信息完成的。对于此操作KnOS还有一个略微不同的版本，称为“集储”。比如我们问一个更难的问题，类似-“Pinto Beans的库存订单中哪一个的数量＜＝2”。回答此问题的操作被描绘在图11“集储的一个例子”中。在“集储”操作中，用特定的选择标准(库存订单，Pinto Beans，数量＜＝2)从数据库中提取VK集合，并且将其放到一个“集储场”中，以便用布尔操作进行一个整数比较。第一步是从数量情境中取出数据实例＜＝2的项目，并将它们放到“集储场”中。接下来，从库存情境中取出“PintoBeans”的项目，并将它放到“集储场”中。最后，取出库存-订单情境矢量键，即{0，6，3，0}。用一个称为“过滤”的集储操作在矢量键的前3个成分(即{E，R，C})上执行一个整数比较以获得结果，在此例中为{0，6，3，X}。整数比较的结果{0，6，3，2}是问题的答案。
数据在物理介质上的位置：
一个KnOS实现的每个仓库是作为一个容器被储存的，该容器类似于一个基于磁盘或基于存储器的系统中的一个文件。要在物理介质上定位一个项目只需要其矢量键。如果一个项目的矢量键未知，则必须用来自ASCII-betical转换过程(如图15“ASCII-betical转换”所示，并且在上文中说明)的确定该矢量键。根据其矢量键取出一个比如{0，6，8，2}这样的项目有六个步骤，如图16“在物理介质上定位项目{0，6，8，2}”所示。
步骤#1-情境索引。从一个仓库文件中取出的第一个数据库人工产物是仓库的情境索引，在此例中是对于仓库#6的。情境索引包含两部分条目的一个有序的系列，对于特定仓库中的每一个情境有一个条目。情境索引条目的第一部分是情境在仓库内的实际号码，即矢量键的“C”维。这里显示的前四个条目表示仓库#6的前四个情境-情境#1、#2、#7和#8。由于情境索引是有序的，因此从图16的例子中显见情境#3、#4、#5和#6已经被删除或者由于某种原因就从来没被添加过。情境索引条目的第二部分是每个情境在情境定位器中的顺序。条目的第二部分显示了仓库#6的情境#8是情境定位器中的第三个情境。
步骤#2-情境定位器。仓库文件中的下一个人工产物被称为情境定位器，它与情境索引的物理构造完全相同。与情境索引类似，情境定位器对于仓库中的每个情境也具有一个两部分条目，但是情境定位器不是一个有序的列表。情境定位器是一个编入索引的(indexed)列表，它是按照情境索引被编入索引的。上述步骤#1确定仓库#6的情境#8是情境定位器列表中的第三情境条目。情境定位器列表中情境#8的条目的第一部分(即“#1”)显示在物理介质上情境#8就在情境#1之前。情境定位器条目的第二部分显示情境#8开始于仓库文件的情境扇区的第五“页”。这被称为“偏置为5”。页大小被确定为任何按数据对象粒度和大多数KnOS对象的平均大小来说对于仓库管理是最佳的大小。为了最小化浪费的空间，最大化访问吞量，并且处理长度动态可变的项目，通常采用一种相当精细的颗粒方法。但是页大小可以在运行时确定，以便适合所使用的任何储存介质以及任何典型的数据对象大小，并且适应于KnOS主要用途，不论它是一个只读数据市场，还是数据采掘应用，还是一个每个事务中有许多项目更新的实时动态数据模型。在一个多媒体应用中，诸如图像或音响文件之样的大型数据对象可以定义典型页大小。不论是哪种应用，一个规则是两个KnOS对象，不论是情境还是项目，永远不会被包含在同一页内。如果一个特定对象没有填满一页，则页中剩余部分被留空。
步骤#3-情境BLOB。仓库#6中的每个情境以及每个情境的每个项目，作为一个BLOB被储存在仓库#6的物理介质上。根据上述步骤#2中获得的位置(即“偏置为5”)，缓冲磁盘上以仓库的情境部分的第五页开始的一个轨道/扇区。被缓冲的磁盘轨道/扇区将包含多于由情境#8所占的4页的信息。情境#8的头部开始在仓库文件的情境部分的第五页上。前四个字是情境的矢量键，在此例中为{0，6，8，0}，接下来是情境的项目地图。情境#8的项目地图指出项目索引和项目定位器位于情境内的什么位置。这两个列表在构造和用途上与情境索引和情境定位器是相似的。
步骤#4-项目索引。根据情境#8中的项目地图，从情境#8BLOB中取出情境的项目索引。项目索引包含两部分条目的一个有序系列，对于特定情境中的每个项目有一个条目。项目索引的第一部分项目在情境内的实际号码，或矢量键的I维。这里显示的前四个条目表示情境#8的前四个项目-项目#1、#2、#5和#6。因为项目索引是有序的，因此从图16的例子中显见情境#4和#5已经被删除。项目索引条目的第二部分是每个项目在项目定位器中的顺序。条目的第二部分显示了情境#8的项目#2是项目定位器中的第三个情境。
步骤#5-项目定位器。从情境BLOB中取出的下一个人工产物被称为项目定位器，它与项目索引的物理构造完全相同。与项目索引类似，项目定位器对于情境中的每个项目也具有一个两部分条目，但是项目定位器不是一个有序的列表。项目定位器是一个编入索引的列表，它是按照项目索引被编入索引的。上述步骤#4确定情境#8的项目#2是项目定位器列表中的第三项目条目。项目定位器列表中项目#8的条目的第一部分(即“#6”)显示在物理介质上项目#2就在项目#6之前。项目定位器条目的第二部分显示项目#6开始于仓库文件的项目扇区的第七“页”。这也被称为“偏置为7”。页大小再次被确定为对于大多数KnOS对象的大小来说最佳的大小，因为没有两个KnOS对象，不论是情境还是项目，会被包含在同一页内。如果一个特定对象没有填满一页，则页中剩余部分被留空。
步骤#6-项目BLOB。情境#6中的每个项目以及仓库的每个情境作为一个BLOB被储存在仓库#6的物理介质上。根据上述步骤#5中获得的位置(即“偏置为7”)，缓冲磁盘上以仓库的项目部分的第七页开始的一个轨道/扇区。被缓冲的磁盘轨道/扇区将包含多于由项目#2所占的2页的信息。项目#2的头部开始在仓库文件的项目部分的第七页上。正如一直以来的情况那样，一个对象的前四个字是项目的矢量键，在此例中为{0，6，8，2}，接下来是项目的项目地图。
以上操作完成了在物理介质上定位项目{0，6，8，2}所必要的步骤。注意前述六个步骤是对于物理介质访问的一个逻辑讨论。情境BLOB(来自步骤#3)和项目BLOB(来自步骤#6)可被视为用于“偏置”用途的单独的文件部分。实际，图16中所示的全部六个KnOS对象都被混合在相同的邻近的物理介质上仓库#6的文件内。情境和项目从结构上来看非常相似，通过对象头部中的一个“对象类型”来区分。此外“偏置”(定位器)也可以是一个“有效地址”，其中被引用的页标识符是根据储存介质的内部构造间接得出的。
物理介质的更新：
一个KnOS“仓库”由多个BLOB的文件组成。BLOB通过图16“在物理介质上定位项目{0，6，8，2}”中所示的引用被独立访问。情境BLOB和项目BLOB被混合在仓库文件中，没有特定的顺序，如图19和20“在物理介质上更新项目{0，6，8，2}(I&II)”所示。BLOB不要求KnOS的排序以便有效操作，因为所有必要的信息都被封装在每个BLOB中。顺序独立性是KnOS从其特定的封装形式中赢得的核心优点之一。KnOS数据结构的每个BLOB被编入索引以便定位。BLOB在磁盘上的顺序对于KnOS不重要，因为每个BLOB是用该特定的BLOB的所有关联的和相关的知识被完全封装的。
每个BLOB，不论是情境还是项目，都被分配了一个关于磁盘上被分配的页的特定号码，以便每个BLOB的最后页可包含若干空闲空间。可以将页大小建立为在一页上收藏大多数BLOB，并且在页上留下的空闲空间尽可能少。在一个首选实施全中，根据应用的优化要求、平均BLOB大小和储存BLOB的物理介质的结构化属性来确定页大小。
所有BLOB都可能随着每次更新在大小上增长或缩小。如果一次更新后，如果一个BLOB仍然要求它被分配的页数目，则它会以更新后的格式被写回磁盘上，并且写入同样的页块中。如果更新后它要求的页数与其先前的页分配相比更多或更少，则KnOS将估计更新磁盘所需的最小工作量。BLOB大小的多样性根据应用变化。一般来说，BLOB越大，越不希望移动它。如果一个扩展后的BLOB仍能适应其本来的空间加上下一个BLOB被分配的空间，则扩展后的BLOB可以被返回到其原来的偏置位置，而下一个BLOB可能被移开。
KnOS可以按照页标识符引用保存所有被分配的邻近的页块的一个驻留存储器的“注册”，以一个相关联的索引进入占领项目的矢量键的一个定位器中。每个项目的这种物理到逻辑映射允许了用一个完全关联的模型实现不同的存储器和磁盘管理方案，该模型是完全包含在KnOS内的，从而不需要运行第三方磁盘操作系统或存储器管理系统。
一个附加的空闲空间管理情境可以被例示到每个仓库中，它带有一套项目，其数据实例是可用的邻近页的号码，例如，数据实例等于“1”的项目是所有1页分配的列表，等等，并且其中每个项目具有一个VK集合，页定位器引用，作为对仓库文件中已被使用的部分内的所有去分配的邻近页块的索引，其中大小是每个项目的数据实例。如果BLOB大小增大和减小有或多或少平均的分配，则首选以下空间注册方案：
在此实现中，KnOS将会简单地在磁盘上重新定位一个更新后的BLOB。为了做到这一点，KnOS检索空闲空间情境的数据实例是更新后的BLOB所要求的页数目的项目。然后它从该项目的页标识符引用列表中获得最后添加的所要求的页数的邻近页块的页标识符，并且将更新后的BLOB复制到新位置，更新BLOB项目的相适的定位器引用，并且从空闲空间情境的项目页标识符引用列表中删除该页标识符。然后KnOS将先前被占用的页块添加到空闲空间情境的项目的页标识符引用列表中，该项目的标识符是页数目。
例如，如果一个KnOS对象当前要求5页，更新后要求7页，则KnOS首先将检查空间注册，看看是否有任何可用的带有七个邻近的页的“偏置”。如果有的话，KnOS将会(a)取出一个可用的7-页偏置；(b)从空间注册中删除新的空间；(c)将更新后的KnOS对象写到该位置；(d)用新的偏置位置更新情境或项目定位器中的条目第二半；以及(e)将旧的空出的5-页偏置位置添加到开放空间注册中。如果没有开放空间正好具有所要求的页数，则KnOS将会把更新后的对象附到文件结尾，如图19所示。
由于此磁盘管理方案，随着时间过去，某些未被分配的页(关于例子请参见图19)将发展到整个仓库文件中。只要总磁盘空间不成问题，则这些空洞对于KnOS就不成问题。与RDBMS不同，KnOS吞吐量效率不会在磁盘变得无组织时显著退化；BLOB在磁盘上的顺序对于访问方案是不重要的。只要关系到KnOS，磁盘文件就是内在无组织的。
如果磁盘利用对于客户来说变得不可接收地低，则KnOS将会开始一个背景操作，以便将仓库的BLOB复制到一个新文件中，以便消除BLOB之间的任何未被分配的页。不尝试按引用标识符对BLOB排序。但是，可以根据BLOB的项目标识符在其情境内的顺序来复制BLOB。这将线性化一个仓库中的所有项目，如果情境内容经常从仓库被整体请求的话，这将减少磁盘头搜寻时间。否则现存的BLOB顺序将被复制到新的磁盘区域中。复制的目的是使BLOB被端对端地排列，消除BLOB之间的任何未被分配的页。这一点可以在不中断KnOS的任何当前操作的情况下完成。如果任何正被移动的BLOB被操作系统所访问，则更新只是被高速缓冲直到复制过程结束，然后被高速缓冲的更新被写到磁盘。
在一个替换方案中，采用了如图19所示的一种“驱逐”方法。用这种方法未被分配的页的问题实质上就不存在了。当每个项目增长时，通过将一个或多个占用它所需的空间的项目移出这些空间来提供它需要增长的空间，这些项目或者被移动到仓库的被使用的部分末尾的空闲空间，或者被移动到空间注册中找到的一个具有匹配大小的空闲页块中(如果激活了空间注册的话)。然后产生的空间被分配给增长后的项目。由于在大多数应用中项目往往会增长，不论一个项目通过清除道路获得什么空闲空间，最终都会随着它持续增长被该项目所用。在此方法中，通过删除一个项目留下的空间或者可以被分配给存储器中在它之前的项目，或者可以被添加到空间注册中，用于重新分配给新的或移动后的项目。
内容意识：
一个KnOS实现可以支持关键字搜索和有限文本搜索能力，作为一个结构化数据应用程序的核心实施例的一部分。比如，拥有一个结构化数据应用程序的一个企业还要求在所有员工简历上提供文本搜索和关键字搜索能力。以下是KnOS中如何完成这一点。
首选，每个个人的简历按多页PDF格式(Adobe Systems的一个和)作为个人项目中的一个内嵌的项目被添加。则简历看起来与图13“一个KnOS项目的结构”中的内嵌的项目(即电话号码和街道地址)类似。简历的PDF只是作为每个个人的项目内的一个BLOB或一个压缩的BLOB被储存。
第二步是建立和繁殖一个“关键字”情境。此情境将对于所有简历中的每个非平凡字(不是连词、冠词等)包含一个项目。字本身是关键字情境中的每个项目的数据实例。无论何时当一个新的或修改后的简历被添加到个人情境中时，对于特定个人的所有先前的关联的关键字引用都将被删除，并且对于简历中每个和所有唯一的非平凡字的一个新的关联引用被添加到关键字情境中，当然也双向地被添加到特定的个人的项目中。这样关键字情境中的每个项目将包括一个到个人情境中的正确的个人项目的矢量键。例如，如果简历字是“carpentry”，则数据实例＝“carpentry的关键字项目将包含到所有简历中具有“carpentry”一字的个人的矢量键的特定VK集合。
为了在简历上进行一个文本搜索，用户将被提示输入一串字串用于搜索。每个搜索字首先将在ASCII-betical中被转换，以确定每个搜索字的关键字项目矢量键(关于如何完成此操作的一个例子请参见图15“ASCII-betical转换”)。然后每个搜索字的正确关键字项目以个人情境“被集储”以确定哪个个人项目具有一份确切带有这些字的简历。此过程与图11“集储的一个例子”所示的“集储”操作相同。集储操作结果是简历拥有所有搜索关键字的所有个人的矢量键的列表。个人数据实例的列表将被返回给用户，或者个人项目的一个简单取出将产生作为内嵌的PDF的实际简历。
将一份PDF格式的简历添加到每个个人项目中将向每个个人项目添加相当大的大小。如果个人项目的常规使用不要求简历，则将简历的实际PDF内嵌到一个单独的称为简历的标签集合情境中对于吞吐量效率将可能是有利的(关于标签集合情境的说明请参见下文)。然后实际的简历PDF只有在需要时才被取出，而不是在每次一个个人项目被取出时。实际上，这是关于某个东西是否作为一个内嵌的项目被包括在基本项目中的通用测试的一部分。
将遗产数据库同化到KnOS数据库中：
作为一个实际问题，几乎所有企业都具有一个表格式的遗产数据仓库。KnOS发明作为一个DBMS的有用性在很大程度上是通过其吸收或同化储存在表中的大量遗产数据的能力来判定的。对于大部分来说，此遗产数据存在于未协调的平面文件中，而不是理想的规范(3NF)格式。KnOS在吸收完全规范化的关系结构时工作得最好。
一套规范化的(3NF)关系结构和相关联的数据可以通过一个良好定义的过程被转换或同化到KnOS情境和项目中。关系数据库是由三种类型的规范化关系(表)组成的-被命名的(即主关系)，未被命名的(关联关系)和查找-并且每类关系都以不同的方式被同化到KnOS中。这一节首先说明图1“关系数据模型”所示的关系数据库将被如何同化到KnOS中。由于大多数遗产应用程序利用平面文件(不是关系表)，因此这一节的剩余部分都说明如何处理一个平面文件以便好像它是一个关系数据库那样将它标示，以便用于同化。
同化被命名的(主)关系：
一个名称是赋予一个关系(表)的每个元组(行)的一个唯一标识符。对于具有一个名称的资格的某种东西来说，它必须是唯一的，并且用户必须能够识别它。生活中的一个事实是用户可以命名某些关系元组，而不命名另一些关系元组。这是因为某些关系对于用户来说太复杂了以至于无法命名。未被命名的元组只通过给出其存在性的线索来描述。
在关系模型中，一个被命名的关系通常被称为一个主关系。被命名的关系的一个特殊的情况-查找关系-不被视为主关系。对于这种关系，参见下文的“同化查找表”一节。在图1和2中，库存主关系是一个被命名的关系，其元组被命名为“Pinto Beans”、“KidneyBeans”、“White Beans”和“Wax Beans”。一个被命名的关系的其他所有唯一的列都作为一列被同化到每个情境中。正如先前所提出的，一个KnOS情境类似于一个关系列或属性。
如图3所示，库存主关系将被同化到两个KnOS情境中-一个情境用于“库存”属性，一个情境用于“价格”属性。如果库存关系中有更多属性，则每个唯一的属性将在KnOS中具有其自身的情境。如果情境是相同的，则属性在一个唯一基础上被同化到KnOS中。如果“价格”属性以相同的关系情境(例如某种东西的价格)出现在四个不同的关系中，则KnOS将只有一个“价格”情境。接下来，库存主关系中的每个元组被分配到KnOS的被命名的属性情境中的一个项目，在此例中是一个“库存”情境。每个被命名的行必须在被命名的情境中有一个项目。库存关系中的四行意味着“库存”情境中的四个项目，对于每一个被命名的项目有一行，如图2所示。对于主关系中的所有其他属性，对于属性每个唯一值创建一个KnOS项目。对于“价格”属性，对于每个不同的价格将有一个项目。在此例中，四个价格意味着四个项目。如果“Pinto Beans”和“Kidney Beans”都是每箱价钱都是$11.10，则“价格”情境将只有三个项目(即，$11.10、$13.45和$18.72)。
被命名的关系的每个元组表示许多内嵌的关系。为了记录每个元组内的关系，VK集合被插入到每个情境中，以完全描述“库存”和“价格”之间的关联。完整的同化被描绘在图15中。每个被命名的关系将以这种方式被同化。
同化未被命名的(关联的)关系：
在关系模型中，一个未被命名的关系通常被称为一个关联关系，因为它是用于描述关系之间的一个复杂关联的，这些关系是由FK定义。由于其复杂性，一个关联关系通常没有涉及个体元组的方便的名称。如图3“同化一个’关联的’关系”所示，库存-订单关系是关联的。它将被命名的库存(“Pinto Beans”、“Kidney Beans”、“White Beans”和“Wax Beans”)关联到命名的客户订单号(#1111、#1117、#1118和#1119)，如图8“数据表示的比较”底部所示。关联的关系库存-订单关联两个被命名的关系(库存和订单)，但是本身不是一个被命名的关系，意味着用户不能直接命名关系的单独元组。
与关系模型相对，KnOS设计对于每个关系要求一个被命名的情境，以表示关系的元组。因此，如果一个特定的关系未被命名-元组不能被单个PK属性唯一标识-则KnOS将要求一个用于特定关系的单独的代理的被命名的情境。如图3所示，KnOS中的代理“库存-订单”情境在项目上没有名称(其原因与关系元组未被命名的原因相同)。不同于为关系创建一个特殊的代理情境，一个未被命名的关系以与一个命名的关系相同的方式被同化。
被命名的和未被命名的关系之间的差别在图2和3中最明显。一个被命名的关系作为用于关系的每个具有不同情境的属性的一个KnOS情境被同化；一个未被命名的关系作为用于关系的每个属性的一个KnOS情境加上用于图3中未被命名的关系本身的一个代理的被命名的情境被同化，代理情境是情境#3：库存-订单。
应该注意对于未被命名的关系的所谓的代理情境只是关系意义上的一个代理，即对于关系理论来说它是一个未被命名的关系的一个代理。只要涉及到KnOS，则它是一个与其他情境没有区别的情境。如果从草稿中创建一个数据模型，没有关系模型作为先例，则该规则将不适用。相反，KnOS模型将对于每个概念包含一个行状情境，而对于每个带有一个不同的情境的属性包含一个列状情境。
一个关联的关系同化到一个表示关系本身的KnOS情境中，以及用于关系的每个唯一的属性的一个KnOS情境中。库存-订单关系同化到一个代理“库存-订单”情境中，以及用于关系中的“库存”、“订单”和“数量”的一个KnOS情境中。如图2所示，然后矢量键被连接成VK集合，并被封装到容器中，以反映将三个属性绑定成一个关系的关系。
图5“将关系同化到KnOS情境中”描绘了被命名的和未被命名的关系同化后将如何出现在KnOS中。图5顶部的两个关系按照其结构来说是非常依赖于应用的。图5中的关系化关系下面的五个KnOS结构全都是相同的，并且不依赖于特定应用。每个项目的物理结构完全相同-一个自引用的矢量键，接下来是一个包含名称(或名称代理)的数据实例，接下来是VK集合以及所包括的任何内嵌的元素。
同化查找关系：
关系数据库设计通过一种称为查找关系的特殊的被命名的关系实现了属性级别完整性。一个查找关系是一个用于记录一个特定属性的允许值域的平凡关系。一个查找关系具有两列-一个人工键(AK)，它是属性值的一个代理，以及一个名称，它是属性数据值本身。功能应用程序中的许可将限制谁能够从一个查找关系中添加、编辑或删除值。在每个利用这种域受限的属性的关系中，AK代理总是被属性数据值取代。
查找表是被同化到KnOS中的第一样东西。假设KnOS不同化AK，每个查找关系同化到一个KnOS容器。当使用查找关系的被命名的和未被命名的表被同化到KnOS中时，AK代理关系被删除，选择对于表示查找属性的容器的一个直接关系。
例如，一个关系应用程序可能选择将属性“颜色”限制为三个值-“红”、“蓝”和“绿”。为了确保应用程序用户不会将其他颜色分配给关系，一个称为“颜色”的查找关系将被创建，它只有三个元组-“红”、“蓝”和“绿”。每个元组将被分配一个代理属性“颜色代码”(AK)，其值分别为“1”、“2”和“3”。在关系数据库的整个剩余部分，代理属性“颜色代码”都将代替“颜色”{“红”、“蓝”、“绿”}本身被使用。
在此例中，KnOS将首先将颜色查找关系同化到一个“颜色”情境中，该情境带有三个项目，其数据实例为＝“红”、“蓝”和“绿”。在同化一个关系中每次遇到AK“颜色代码”时，KnOS将消除“颜色代码”{1，2，3}AK属性，以选取“颜色”属性的KnOS矢量键，表示“颜色”情境中的三个项目{“红”、“蓝”、“绿”}。来自关系数据库的关联将被保持，但AK“颜色代码”将不会存在于KnOS实现中。基于KnOS的功能应用程序必须制定关于谁能和谁不能添加、编辑或删除“颜色”情境中的类似的允许控制。这将完成与查找关系在关系实现中所完成的同的属性级别完整度。
同化平面文件：
先前的三节说明了一个完全规范化的关系数据库如何被同化到KnOS中。但是许多到KnOS格式的数据库同化将来自与关系表相对的“平面文件”。一个平面文件也是一个表，但它不遵守关系的规范化规则(被命名的、未被命名的或查找)。相反平面文件是按照用户“视图”来被组织的，以支持特定应用程序。因此，平面文件太无组织以致于无法直接同化。
为了被同化到KnOS格式中，一个平面文件必须首先被标示，如以下章节中所述，一个称为规范化的关系过程。一旦每个平面文件已经按如下所述的方式被标示并且准备好，它将按前述章节的方式被同化到一个KnOS格式中。在将平面文件同化到一个KnOS格式之前不必首先将平面文件解析并分离成关系表。标示可以被应用于平面文件，以使得它们能够像被命名的、未被命名的或查找关系表那样被软件同化。
以下章节描述将平面文件像关系表那样分析和标示的过程。为了同化平面文件，KnOS要求一段称为同化器的专用软件，它能够读取平面文件标示，如下所述，并且将信息从平面文件格式转换为KnOS格式。
标识不需要的数据：
转换一个平面文件的第一步是标识不需要的数据。随着时间的推移，任何基于平面文件的计算机系统都会获取不必要的数据列。这些列是平面文件内的不再被应用程序软件所使用的信息列。标识不需要的数据列的最直接和精确的方式是将新用户视图的所需集合的每个元素映射到平面文件的不同列。此过程被称为视图建模。一个视图是终端用户与平面文件中的信息的任何交互，通常是屏幕、报告和接口。一旦平面文件已经以这种方式被映射到“视图”中，平面文件中的许多列将可能不被映射到任何要求的容量中。平面文件中的这些列是不需要的数据的候选者，它们不会被同化。
必须让新应用程序的用户检查不需要的列的初始标示以便确认信息确实是不必要的。许多被标记为不需要的信息将是已经被事件所取代的遗产应用程序的属性。信息被放置到平面文件中，以便在某个预先的时刻服务遗产应用程序。当遗产应用程序被更改为消除该特征时，平面文件不被纠正以消除未使用的信息。遗产应用程序越老，平面文件中包含的不必要的数据列越多。
通常，侯选的不需要的数据列是被平面文件应用程序软件用来处理信息的物理表示(标记、指示符等)。这种标记和指示符可能是或不是新应用程序所要求的。必须对照新应用程序的行为模型验证每个这种标记或指示符，以确定可通过其他方式(新应用程序中的软件)重新建立特定的标记或指示符。如果不能的话，包含该标记或指示符的列必须被标记以用于同化。
标识导出的数据：
第二步是标识导出的数据。平面文件中的许多不映射到用户视图的信息将是可以直接从其他不需要的数据列导出的数据值。导出的数据，例如数字的整列，被放到平面文件中，以节省计算资源。不论导出的数据是否被新应用程序所需要，它都不被同化。相反，导出的数据或者被用户的应用程序在运行时导出，或者如果导出的数据被储存，在同化时被KnOS再次导出。平面文件中的导出的数据的所有列必须被标识并且标记为不必同化。
对于任何将储存在KnOS中的导出的数据，文件标示必须包含导出算法。同化器软件的预处理器将尝试根据算法重新创建导出的数据，并且报告相对于平面文件中包含的导出的数据的任何差异。应该由新应用程序的用户检查任何这种差异，以确保差异是有效的(即算法是精确的)。
分解合成信息：
步骤3是分解合成信息。平面文件中的合成信息是一种形式的导出数据，它由原子属性的连接组成，用于特殊用途，比如排序和打印(或者常用于触发特殊的处理条件)。每个这种合成信息列都必须被分析和分解。通常，合成信息列将包含需要的数据的一个或多个核，它们不出现在平面文件的其他任何列中。在这些情况下，平面文件应该被预处理，以便从合成属性中提取一个或多个必要的信息核，并且将其放到平面文件中的新列中(为了用于同化)。一旦必要的一个或多个核被提取到了平面文件中它们自己的新列中，合成信息的列就被标记为不需要的(并且不被同化)。
标记记录的拷贝：
步骤4是标识复本并标记记录的拷贝。同化过程中最难的部分涉及复制的信息列之间的同步误差。平面文件中的信息列(属性)很可能被复制。只要被复制的属性对于相同的主键值具有不同的值，则会发生一个同步误差。同步误差必须被标识并且记录的拷贝必须被标记为要同化(即不同的值中哪一个是精确的)。属性的其余复本被标记为不需要的(并且不被同化)。
此过程中的第一步是标识复制属性的主键。然后KnOS同化预处理器必须将主键的每个唯一值与复制属性的所有值相比较。在理想情况下，对于主键的每个唯一实例，所有复制的属性应该具有相同的值(毕竟这才是复制的意义)。当预处理器检查此条件时，它很可能会找到许多违反的情况，并不真是复本的复本。没有计算机化的过程能够确定这些不同的值中哪个是精确的。也可能是主键已经被不正确地访问，复本不真是复本(例如，不同的地址实际上可能是帐单(billing)地址，发票(invoicing)地址等)。在这些情况下，纠正复制的平面文件列的主键将纠正同步误差。
对于脱离同步的真正复本，分析者必须以应用程序的用户来验证同步误差，并且为每个被标识的数据完整性误差确定一种处理。最好的结果是用户人群确定复制的列中的某些列是记录的拷贝(即将被同化的数据列)，从而允许其他所有复制的列被标记为不需要的(并且不被同化)。用户可要求每个同步误差被单独解决。此分析的结果必须被保存以便同化软件使用。
标识规范化的表：
步骤5是规范化平面文件。对于平面文件中剩余的每个需要的信息列，分析者必须标识其主键(平面文件中唯一标识该列中的值的一个或多个信息列)。此操作标识平面文件内的规范化的关系表，因为每个不同的主键表示一个不同的规范化的表。不必将平面文件解析为单独的规范化的表结构(如果每个信息列以它的正确主键被标记(关联)的话，则规范化的表可共存于一个平面文件内)。在KnOS中，每个主键将被唯一地关联到一个行状情境。
标识人工键：
步骤6是标识和消除人工键。表通常具有人工键(AK)，这些人工键是被创造为唯一的标识号码。AK通常被PK取代，不然这些PK就将是长的ASCII字符串或可能具有唯一性问题。例如，用户名称可能是一个个人表的真正OK，但是名称对于索引用途来说太长的，并且两个个个人可能具有相同的名称。如果存在一个方便的唯一的数字的PK，例如一个社会安全号码，则平面文件通常会包含它。如果不存在方便的唯一号码来为一个主关系编号，则平面文件将包含一个用于该用途的AK。如果这样的AK存在于平面文件中，则它们必须被标识为不需要的，并且不被同化。相反，标识正确的PK作为用户可访问的属性(标识AK已被取代)的一列或多列。
一旦已经为每个AK标识了正确的PK，则必须用同化器的一个预处理运行标识平面文件中的任何唯一性问题。如果一个特定的规范化的表的正确PK具有相同的值但是有不同的AK，则必须由应用程序的用户来解决重复的PK值。必须确定一个方案以便在同化时值是唯一的。解决方案可能就只不过是在字符串末尾添加一个整数(例如，John Paul Jones1，John Paul Jones2)。在解决完整性误差前平面文件中的正确PK必须被转换为唯一值。
在多个主键候选者之间选择：
步骤7是在多个候选者存在时选择一个PK。通常一个平面文件中的一个所需要的信息列对于其PK将具有多个候选者。当发生这种情况时，分析者必须确定同化多个键的最佳方式。候选者之一必须被选择为KnOS的首要键。所有的非键列和剩余的候选PK在同化时被关联到主键。由于性能原因，当从多个候选者中选择首要PK时必须进行某种照管。
例如，用户名称和社会安全号码可能是一个个人表的竞争的候选PK。任意一个都可用作为个人表同化的被命名的行状情境。应该根据用户更经常用哪个来访问表中的记录来做出选择。如果用户最常按照名称访问个人信息，则个人名称是首要键的正确的数据实例值。
一旦已经选择了首要键，则必须评估其他PK候选者以便进行处理。如果个人名称是KnOS的个人情境的正确属性，则SSN必须与它紧密联系在一起。SSN可以具有它自己的KnOS情境，尤其如果它具有相当多重要的独立访问的话。但是，更可能每次使用个人名称时，也要求SSN。如果是这样的话，则将SSN视为个人情境中的一个项目内嵌的元素可能对于性能是有利的。这种决定应该在同化前做出。
解决完整性误差(表级别完整性)：
步骤8是建立表级别完整性。一旦完成此标示，则必须预处理平面文件以标识参考的完整性误差。只要平面文件中的一个PK的一个特定值对于该PK标识的数据列以不同的值出现多次，则会出现一个参考的完整性误差。换句话说，如果一个特定的PK标识列A、B和C，并且PK的一个特定值(实例)出现多次，则A、B和C的值对于每次出现都必须是相同的。如果不是的话，则它是平面文件中的一个表级别完整性误差。参考的完整性误差可能是两种情况中的一种-或者是被标识的PK结构是不正确的，或者平面文件中有被破坏的值。一旦已经纠正了PK结构误差，则应该由应用程序的用户验证和解决任何剩余的被破坏的值。
不同的用户人群可能有不同的纠正这种平面文件中的参考的完整性误差的方法。某些用户可能允许同化软件任意选择多个值中的一个，例如，可能是遇到的第一个值。其他用户可能要求通过分析解决每个参考的误差。在极端情况下，用户可能实际上会重新设立平面文件以消除误差。用于解决参考的完整性误差的方法取决于特定实例中的精确度的重要程度。
标准化查找(属性级别完整性)：
步骤9是建立属性级别完整性。平面文件中的许多列可能被标识为查找值。在这种情况下，用户将为属性指定一个取值范围，以便在新的应用程序中建立属性级别完整性。平面文件中的取值范围几乎肯定不会符合新的查找属性所需的取值范围。KnOS同化软件具有接收一个平面文件查找值到标准化查找值的用户映射的能力。同化器首先将特定查找列中的值的范围与用户为该列选择的标准取值范围相比较。不符合的值必须被映射到符合的值。此过程可能会使得标准值列表中的变化成为必要(即某些范围外的值将是用户在编译标准列表时未能标识的正确的值)。一旦完成，同化器软件在同化任何被标记为查找的列时将使用此交叉引用的映射。
这样就完成了平面文件的预处理。现在以符合被命名的、未被命名的和查找关系的关系标准化规则以及适于同化到KnOS中的方式标记了它。
扩展的结构-分类和情境：
在某些应用中，某些KnoS情境可能有关联范围上非常复杂的具有非常大的VK集合的项目。极大的项目更难以处理，因为其情境非常广泛。如果一个特定情境的情境难以处理，则情境的VK集合可以根据情境或分类被分割成一个或多个标签集合情境。
一个KnOS标签集合是一种特殊类型的情境，它可以用于记录数据库中的一个分类(classification)或划分(taxonomy)。一个标签集合情境与一个标准情境具有相同的物理构造，只不过它不包含任何独立的项目。相反，一个标签集合情境中的项目是另一个情境中的项目的有效复本或表示，其中另一个情境被称为标签集合情境的基本(base或basing)情境。一个标签集合情境项目中的VK集合或者记录相应的基本情境项目中由VK集合定义的关联的某种子集或分类，或者记录可应用于新创建的情境的关联的一个不同的新的集合。换句话说，一个标签集合情境对于其中的项目记录关联的一个特定的情境，作为VK集合子集。
有三种类型的标签集合情境-标准、多路和合成。一个标准标签集合情境可以根据任何标准情境创建出。一个多路标签集合情境是基于另一个标准标签集合情境的。一个合成标签集合由来自一个或多个基本情境的项目的一个选定的集合组成。以下讨论描述了利用所有这三类标签集合来增强分类，改进情境和改进性能。
应该清楚只有当功能应用程序能够辨别情境时，情境才能改进性能。如果一个分类或划分对于标记访问的功能应用程序不可见，则该应用程序不能按照情境访问信息。如果特定情境对于应用程序不可见，则KnOS没有利用来自情境的改进的基础。其实，它可能实际上会使KnOS慢下来，因为它创建了更多场所，以至于必须查找东西。
标准标签集合情境：
一个标准的标签集合情境可以基于任何标准KnOS情境。在标准情况下，一个标签集合情境的项目数目与基本情境相同，并且相应项目的数据实例也是相同的。从这方面(数目、数据实例和项目构成)来说，标准标签集合情境是基本情境的一个精确复本。接下来，某种情境被应用到基本情境中的VK集合。根据选中的情境，符合的VK集合或VK集合元素被从基本情境项目中移动到匹配的标准标签集合情境项目中。无论何时只要软件应用程序在该特定情境中操作，则它会访问标签集合情境而不是基本情境。当应用程序在除所述特定的情境外的其他情境中操作时，它会使用所述基本情境或另一个标签集合情境。现在基本情境使用起来简单得多，因为已经从中删除了特定的情境。一个标签集合是一种KnOS分类工具，它改进吞吐量性能以及数据和视图建模的一般组织。
例如，一个制造应用程序中的部件情境很可能具有极复杂的项目关系，从而具有非常大的VK集合。部件容器中的一种可能的关联分类或情境将是“材料清单”(BOM)。如果需要的话，部件情境中由VK集合定义的BOM关联可以被分割为一个BOM标准标签集合情境。
一个被称为“部件”的标准情境KnOS可能会用所有部件的部件号码作为其项目数据实例。一个被称为BOM的标签集合情境可能会被建立为，它对于部件情境中的每个部件包含一个项目，其中每个项目具有相同的项目数据实例。然后部件情境中表示BOM关联的父亲和孩子VK集合可以从部件情境中被删除，并且被放到BOM标签集合情境中。其他所有VK集合被留在部件情境中。这样做的效果是从部件情境中删除BOM分类的复杂性，从而减小部件情境中项目的大小，并且改进任何涉及部件的关系到BOM处理的应用程序的吞吐量。无论何时只要一个应用程序需要BOM，它会调用BOM情境而不是部件情境。
KnOS自动保存一个标签集合情境以及它的基本情境的项目之间的一个一对一映射。在此情况下，应用程序软件可能不会从一个KnOS标签集合情境中添加或删除项目。项目添加和删除是由KnOS操作环境处理的。虽然项目永远不会被删除，但是本身上它们只是具有空的VK集合。只有一个项目被添加到基本情境中时项目才被添加到一个标签集合情境，并且只有当相应的项目从基本情境中被删除时，项目才从标签集合情境中被删除。例如，如果一个项目从部件情境中被删除，KnOS将会删除BOM情境中对该部件的所有引用，既包括BOM项目本身，也包含引用它的任何VK集合。从而标签集合情境是“从属”于基本情境的。
对于在一个标准情境中能够标识多少个不同的关联情境是没有限制的。一个标准的KnOS情境可以是任何数目个标签集合情境的基础。例如，部件-售主关联也可以从部件情境中被去除，并且被放到一个称为部件到售主(PTV)的标签集合情境中。然后，涉及谁能供应一个特定部件的查询将调用PTV情境而不是部件情境。通过这种方式，售主情境可以根据部件情境被分割。也可以对售主情境完成同样的操作，从而根据售主情境将部件关联分割成一个售主到部件(VTP)情境。
一个标签集合情境可以在一个方向(例如PTV)上被创建，而不在另一方向上创建一个匹配的标签集合(例如VTP)情境。标签集合可以被独立注入以改进情境或吞吐量。如果情境或吞吐量未被改进，则不必注入一个标签集合以分类由情境按照VK集合定义的关联。
除了下文描述的多路情况外，一个标签集合情境可能并不基于另一个标签集合情境。在以上例子中，由PTV情境中的VK集合定义的关联可能只指向真正的售主情境中的项目，而VTP情境中的关联可能只指向真正的部件情境中的项目。PTV情境中的项目可能不会引用VTP情境中的项目，反之亦然。
可以随时从KnOS中注入、分割或删除这种分类/情境。从而标签集合分类是KnOS中的一种强大的调整工具。例如，如果处理过程中任何时刻确定BOM关联将部件情境标记得不必要地复杂或者太慢以至于无法处理，则BOM标签集合情境可以被创建出现。一旦被创建出来，BOM标签集合情境可以随时被消除(如果它被确定为是不必要的话)。BOM情境的VK集合将会简单地与部件情境的相应的VK集合合并，并且BOM情境会被删除。
KnOS标签集合技术根据情境工作。一个KnOS数据库中情境越多，它处理起来越快。例如，从专用的BOM情境中处理BOM查询比起从一个通用部件情境中处理来快得多。这是因为BOM情境具有一个有限的情境。它可以在需要时被调用，否则就被忽略。对部件情境的操作不会由于BOM关联而添加负担。此外，它意味着情境之间没有KnOS争用。
不混淆KnOS“分类”方案与关系模型中固有的两个类似的吞吐量问题是重要的，这两个问题是稀疏矩阵和行级别争用。
无论何时只要一个关系的属性不应用到所有元组时就会出现一个稀疏矩阵。调整此问题的关系方法是标识关系内的不同分类，并且将“一般”关系的稀疏部件分割成一个或多个“范畴”关系。换句话说，将数据库放到范式中。
如果太多用户同时企图使用同一表和行，则行级别争用会成为一个问题。根据情境将问题表分割成单独的物理表通常能够消除这种类型的争用。
KnOS通常不会遭受稀疏矩阵或行级别争用的麻烦，因为KnOS没有矩阵，也没有行。情境、范畴和分类在KnOS中与在关系建模中比起来是非常不同的。
标签集合情境的多路类型：
任何企业数据库环境中最困难的问题是查询迭代，其中在满足单个查询之前可能需要许多独立的取出。此查询问题在本质上实际上是关联的，而不是关系的。为了得知A是否与F相关联，首先必须得知A与B相关联，然后B与C相关联，...等等，直到E与F相关联。A-B-C-D-E-F是五个离散关联的一个多路合成。这些关联中的每一个都是独立的，并且无论如何都不能被预先确定。为了得知A与F相关联要求接连执行五(5)个完全独立的查询：A-B、B-C、C-D、D-E和E-F。如果根本方案是一个复杂网络或分级(即一个多路)的话，这种类型查询几乎是不可能处理的。在这种情境下，查询“散开”到成百上千个可能的路径。这种类型的查询对一个DBMS提出了严重的工作量问题，因为查询的迭代不能被并行执行。
这种迭代的最佳的现实事件例子是在BOM处理中。一个订货的BOM是部件一个复杂的分级，通常有十级或更多级那么深。一个多级爆发是一个从左到右多路查询的分级版本。它取出一个特定部件的所有孩子、孙子等。一个多级内爆(“在何处被使用”)是从右到左多路查询的分级版本，或者是一个指向网络源的查询的分级版本，它取出一个特定部件项目的所有父亲、祖父等。得知部件项目A是否用于部件项目B的制造中(或者反过来)，可以是一个带有许多次迭代的复杂查询。不幸的是，这种查询往往就用户来说是非常流行的，从而通常代表了一个制造或网络环境中的计算机工作量的很高的百分比。
在KnOS中，可以通过利用一种称为多路(或m-p)类型的特殊类型的标签集合情境将所有这样的查询减少为单次迭代。在上述制造例子中，m-p类型的标签集合情境可以被称为“多级别”。多级别标签集合情境中的项目可以是BOM情境中的项目的复本，其中BOM情境中的项目是部件情境中的项目的复本。对于新的m-p类型的标签集合情境中的每个部件项目，父亲VK集合可包括来自项目的“在何处被使用”的多级内爆的所有部件的矢量键，而孩子VK集合可包括来自项目的多级爆发的所有部件的矢量键。
这种m-p类型的标签集合情境可以在单次迭代中回答任何BOM类型的问题。例如，部件A是否与部件B具有一个BOM关系？在得知A和B的KnOS引用后，可以通过从多级情境中取出任一个项目A或B并且检查看看其VK集合之一是否包含另一个的矢量键来直接回答此查询。部件A和B是否在任何级别属于任何公共的部件C、D、E...，并且如果是的话，是哪些部件？这个看起来简单的查询将会具有如此令人惊愕的处理复杂度以致于它很可能不会被编程为用于一个关系应用程序中。在KnOS中，该查询只要在多级情境的单次迭代中就能被回答-从多级情境中取出A和B的项目，并且比较VK集合看是否匹配。当然，对于BOM分级(例如BOM标签集合情境)的每次修改将要求许多多级内爆和爆发以便为所有受影响的部件纠正由多路标签集合情境中的VK集合定义的关联。更新一个m-p类型的标签集合情境并不容易，但是基本情境BOM中的每次更改可以作为m-p类型情境上的一次原子操作被处理，在工作量允许的情况下处理。对于DBMS来说，在加载或纠正每段分级信息时执行两个操作(内爆和爆发)与每次提出一个迭代查询时一经请求即执行两个操作相比，效率要高得多。通过以这种主要分类所需的关联，KnOS多路类型的标签集合可以使一个制造应用程序的操作效率提高多达两个数量级。
在KnOS中，一个标签集合情境可以被指定为一个多路类型的标签集合情境，并且基于一个第二分类标签集合情境。KnOS将会自动在基本标签集合情境上执行爆发和内爆以获得多路分类标签集合情境，并且在操作中使它保持同步。可以通过指示KnOS根据BOM标签集合情境创建一个m-p类型的情境来在KnOS中建立上述例子中的多级别标签集合情境。不需要其他应用程序代码；KnOS环境处理所述情境的创建。然后，每次在基本BOM情境的VK集合中发生一个变化时，KnOS会自动保持多级别情境中的VK集合同步。从而，只要为任何必须响应多路查询的分级或网络情境建立一个多路类型的标签集合情境就能在KnOS中消除查询迭代。KnOS在没有附加的应用程序代码的情况下处理与维护一个m-p类型的标签集合相关联的所有正在进行的操作。一个多路类型的标签集合情境是一种被支持的KnOS特征。
在关系实现中不能使用类似分类方法，因为关系模型没有方便紧凑的结构来储存和维护这种关联的分类结构。上述KnOS多级情境例中的一个特定部件可以具有任何数目个VK集合，这些VK集合可能编号至上千，这消除了对每个部件一行的单个关系表的使用。因此KnOS多路解决方案的关系实现将是一个带有两列的表，以便表的每行模仿多级别情境中的VK集合。简单来说，关系解决方案将是利用一个表中收藏的大量“自由矢量”的标准关联方案。没有一个并行矢量处理器的话，此表处理将会太慢以致于对迭代问题没有太大帮助。
“视图”的关系调整技术不能用于解决多路问题，因为关系DBMS不能同时管理足够多的“视图”来解决问题。单个关系“视图”本质上是一个预期的查询的结果。如果通过对于每个可能的多路查询用一个视图来建立关系实现(实质上KnOS就是这么做的)，则关系处理器将不能处理视图维护开销。简言这，由查询一个复杂的多路结构(不论是分级的还是网络的)引起的迭代问题，不能在关系模型或者标准的“自由矢量”关联模型中被解决。
KnOS可以通过两种技术实现DBMS效率的显著提高。一个关系“连接”的KnOS等价体处理起来简单得多，并且多路标签集合情境可以被用于消除复杂网络或分级上的查询迭代。这两个问题占常规DBMS的性能问题中的大部分。
合成标签集合情境：
标签集合的最后一种类别被称为“合成”。对于定义应用程序广泛有用的合成标签集合可以以许多不同的方式被形成，用于不同的用途。一个合成标签集合可以由以下部分组成：
一个基本情境的一个完整复制-例如一个字典情境可以被复制；
一个基本情境减去VK集合的一个完整复制；
从情境的任何组合中选出的完全复制的项目的一个集合；
从情境的任何组合减去其VK集合中选出的复制的项目的一个集合-例如一个视图模型。
一个合成标签集合情境内的复制(复本)由KnOS订阅服务根据标签集合类型自动维护。以下例子描述了一个#4合成标签集合情境的使用：
一个应用程序的创建要求定义用户接口，这通常被称为视图建模。在视图建模中，创建某种数据关系的一个特定视图可能需要的引用集合通常会形成多个情境。如果希望构造一个视图以支持一个特定用户的需要，则该视图中的所有显示元素可以被表示为一个合成标签集合中的项目。该标签集合中的显示元素之间的关联对于该特定视图是特定的，从而可以被视为属于该视图的情境。该视图可以是一个合成标签集合。它的项目可以从它们的基本项目存在的任何情境中提取出。情境中的项目，例如“Web显示元素”、“Web页”、“制造商”、“部件”、“组件”和“消费者项目”可以从不同的情境中被取出，并且按以下方式被添加到一个合成标签集合中：一个新的web页被创建并且被添加到web页情境中。
新的web页被从容器中读出，并且用于创建一个新的合成标签集合，该合成标签集合的名称与新的web页相同。选中的显示元素从网络显示元素情境中被读出，并且作为代表被复制到新的web页标签集合...。关于此例的进一步说明请参见“KnOS层”。
在数据建模中，正如标准标签集合中那样，为任何特定项目定义多个情境通常是很重要的。为了扩展BOM和部件例子，其中有几个、几百甚至几千个可能使用或包含一个特定部件的制造出的项目，在其BOM分级的任何级别，可以为每个和全部制造出的项目创建一个不同的合成标签集合，并且来自许多不同部件情境的部件可以被添加到它们所属的地方。来自任何部件情境的(比如来自一个特定的制造商的)任何单独部件可以被添加到任何制造出的项目的BOM标签集合分级中它所属的地方。某些部件，例如垫圈或螺丝铁丝钉，可能出现在几乎所有分级的所有地方。
情境和范围：
标签集合情境可以被创建在一个环境或仓库(E/R)中以改进地理上分散的KnOS实施之间的情境。例如，环境1{1，0，0，0}和环境2{2，0，0，0}中的用户在实现一个KnOS时甚至在相同的应用程序上很可能都会创建相对独立的情境。换句话说，{1，0，0，0}中的VK集合很少会包含环境2{2，0，0，0}中的项目的矢量键，反之亦然。这是因为执行实施的用户没有意识到不同环境中的情境，并且大多对它们不感兴趣。同样的特征可能也适用于仓库。在环境1内，仓库1{1，1，0，0}的用户与仓库2{1，2，0，0}的可能具有不同的情境。
一个KnOS E/R可以为独立存在于一个不同的E/R中的情境或项目调用标签集合情境。不同规则适用于跨E/R边界被调用的标签集合情境：
跨E/R的一个标签集合可以在三个级别中的任何一个上被调用-“被维护的”、“未被维护的”或“本地化的”。一个特定仓库内的标准标签集合情境总是“被维护的”。如果一个标签集合情境是“被维护的”，则自动维护关联，并且保持趋向基本情境或者与基本情境同步。
在一个特定E/R内，一个标签集合情境不能从另一个标签集合情境中被创建，但是在不同的E/R中，标准和标签集合情境都可以被复制，以便它们能被共享。来自一个E/R的一个分类或划分的拷贝可以被复制并且被放到另一个之中。这为一个订阅者E/R的计算组赋予了本地咨询一个标签集合情境的能力，从而在不同的E/R之间提供了一个本地的支持KnOS的窗口。
如果根据一个不同的E/R中的一个情境在一个E/R创建一个未被维护的标签集合情境，则使用的E/R，例如{2，0，0，0}/{2，3，0，0}，作为发表者(主)环境中的一个“订阅者”被建立。这种未被维护的标签集合情境是一幅快照，只在创建时才精确。为了更新快照，订阅者E/R中的一个应用程序必须请求一个更新或安排一个更新请求，在该时刻订阅者E/R从发表者E/R请求一个新的版本。当订阅者从发表者接收到新的标签集合情境版本时，它替换当前的快照。
如果一个标签集合是在“被维护的”基础上跨E/R被创建的，则无论何时只要主情境被更新，更新的拷贝就被广播给订阅者列表，以使得复本能够保持同步。这些发表者/订阅者活动可以直接从KnOS环境中被调用。由于KnOS是以一种通用格式建立在一个多维引用上的，因此E/R之间的引用是相对直接的活动。E/R之间的链接或端口可以作为操作的一个常规部分被创建和删除。
如果一个标签集合是在“本地化”基础上跨环境被创建的，则“本地”视图中初始表示的项目将只具有引用其他也已经被“本地化”并且被表示在一个“本地”标签集合中的项目的VK集合。在其他环境中创建项目的“本地化”表示可能是一个迭代过程，或者作为一个块完成。“本地化”项目的主要原因是为不同于其源环境关联的那些项目创建本地情境关联，同时仍然维持一个与基本项目的关系，以便全局地使所有“本地化”相关。为了进一步扩展BOM和部件例子，假定某种消费者货物的一个制造商在许多国家具有许多设备。在同一消费者项目的制造中使用的某些部件可能来自不同位置的不同制造商，从而在“本地化”标签集合中不同部件将被替换。此外“本地化的”BOM标签集合的关联可能完全不同，然而在相同的分级位置具有相同的部件项目。相同的部件在每个国家的发行人可能不同。其价格可能是以当地货币为单位的，并且订货至交货的时间、数量折扣阈值和最小数量对于每个位置来说可能都是不同的。在此情竞下，“本地化的”标签集合可能对于BOM中的每个部件具有不同的VK集合，即使部件和分级在所有E/R中都是相同的。
KnOS层：
KnOS是一种100％分层的、完全自引用的环境。自引用意味着一个KnOS应用程序的所有成分都按标准项目、情境、仓库和环境被储存在数据库。这包括了所有软件-可调用的函数、数据库API、源代码等。甚至web表都不是作为Java服务器页或活动服务器页被储存的，而是用情境、项目和VK集合被定义的，正如其他任何KnOS特征那样。web页上的按钮和其他活动特征包括一个KnOS矢量键而不是一个URL。在为浏览器包装一个web表之前，KnOS软件将KnOS页描述转换为HTML。
与比如Sun Microsystems的JavaTM标准(Java 2企业版TM或J2EETM)这样的Web计算的标准环境相比，这是一种真正无结构的环境。在J2EE中，在web应用程序服务器空间中必须调用无数Java类。Web应用程序服务器必须既是垂直(较大的处理器)鲁棒的又是水平(更多服务器)鲁棒的以便响应高事务量。相反，KnOS元素可以作为性能指令在网络计算栈中任何地方被运行。例如，应用程序本身和相关联的web页成分可以在客户PC、web应用程序服务器或数据库服务器上被运行。KnOS计算成分的执行位置只取决于应用程序的需要和提供的硬件量。
除了实现的灵活性和优化的性能外，此设计意味着KnOS不依赖于超文本传输协议的(HTTP的)统一资源定位器(URL)来定义基本目录结构和应用程序元素的放置。当使用JSP/ASP时，它们在文件系统中的位置可以很容易地变得混乱。可能存在储存在不同目录中的同一页或代码的许多版本，这取决于每个开发者选择在哪放置它们。无论何时只要执行对应用程序的修改，则非常容易对HTTP和代码的导出实例“失去跟踪”，并且就“错过”了它们，这引入了差异，并且引起了非常难以跟踪并纠正的问题。有了KnOS的话，页定义及它们的导出版本存在于数据库中的一个位置，并且可以在应用程序运行时被更改。这是被允许的，因为一个KnOS web页的每个组成部分是通过项目和VK集合在KnOS数据库中被单独定义的。更改一个或多个页成分项目会自动更改使用这一个或多个项目的web页。
企业可缩放性：
KnOS结构定义了企业可缩放性的性能包络。可能存在防火墙、进入的HTTP调度器、会话管理器、字典管理器和数据服务器的专用节点。与关系计算模型不同，KnOS不要求为了每个用户会话的连续性而保存中间查询结果。因此，HTTP调度是比较简单的(可用性/工作量驱动的)，并且专用于集储、过滤和XML包装的处理器的数目可以根据需要被扩展以处理同时的用户会话的增长。KnOS数据库操作是如此高效和如此可预测以至于通常不需要附加的计算能力来服务同时的用户的额外的数目。但是，数据库处理器的数目可以跨一个松散耦合的群集结构被扩展，或者服务更多的同时的会话，或者服务大小达到兆兆字节范围的特大容量磁盘。
企业结构：
图21“KnOS可缩放性”描绘了在最坏情况假设下可能如何配置一个典型的高端站点。一个范围内的松散耦合处理节点被一条高速总线互联。HTTP请求在防火墙节点被接收。如果被清除，HTTP请求被转发到一个专用于HTTP调度的节点。存在“k”个web应用程序服务器，其中每个服务器可以拥有许多处理器，这取决于必须服务的同时使用的用户人群大小以及由集储、过滤和XML包装中的特定应用程序提出的难度。这个例子显示两个仓库被专用于目录，其中{1，1，2，0}是{1，1，1，0}的系统维护的复本(标签集合)。最后有3-“n”个仓库被专用于数据库服务。每个数据库服务器管理约达100GB的非冗余数据。通常应用程序将支持一个数据库服务器的逻辑划分方案，以便web应用程序服务器能够知道什么数据位于什么服务器上。这个例子假定没有逻辑地划分数据的能力。项目根据它们何时被接收到或者与它们的访问配置相关联的工作量被分散在3-“n”个数据服务器仓库中。
图21中所示的典型场景将像下面这样工作：
步骤#1-一个HTTP请求在互联网上被接收到，并且在防火墙处被处理。
步骤#2-如果适当的话，HTTP请求被转发给单个调度器节点。
步骤#3-调度器或者处理登录或者认证内嵌/加密在HTTP消息中的会话证书。如果可靠的话，调度器根据工作量在起作用的web应用程序服务器之间分流请求。在此例中，HTTP请求被调度到web应用程序服务器#1以便服务。
步骤#4-web应用程序服务器#1通过解析/解密会话证书和HTTP消息建立会话。
步骤#5-如果有效的话，HTTP消息将要求一段或多段信息。Web应用程序服务器#1被分配给字典服务器{1，2，0，0}以服务ASCII-betical搜索请求。Web应用程序服务器#1用来自事务的一个ASCII值集合为字典服务器{1，1，2，0}分配任务，请求ASCII-betical转换。服务器{1，1，2，0}执行被请求的ASCII-betical转换，并且将被请求的项目矢量键返回给web应用程序服务器#1上的会话。
步骤#6-web应用程序服务器#1接收被请求的项目矢量键并且根据每个项目矢量键中的仓库标识符号码向数据服务器发布一套定向的、被引用的取出。换句话说，项目矢量键标识哪个服务器包含每个被要求的项目。仓库{1，1，3，0}、{1，1，4，0}和{1，1，n，0}的数据服务器以图21中所示的方式为被请求的项目进行被引用的取出。数据服务器将被请求的项目返回给请求的会话管理器，web应用程序服务器#1。
步骤#7-会话管理器将接收被请求的项目并且进行所指示的集储/过滤操作，如果必要的话重复步骤#6以取出额外的数据。
步骤#8-然后web应用程序服务器将遵循应用程序代码中包含的指令并且取出可能从数据服务器请求的任何额外的答案值。
步骤#9-然后web应用程序服务器将生成web页并包装XML，加密会话证书，构成HTTP响应并将它返回给HTTP调度器。此时，会话完成并且被从web应用程序服务器中清除。HTTP调度器将通过防火墙把HTTP响应调度给互联网，以便返回给请求者。
由于KnOS结构是100％并行的，因此关系选择操作的等价物(步骤#6)可以从关系连接的等价物中分离出来。作为一个RDBMS的核心瓶颈的连接(集储/过滤)操作的的KnOS等价物可以在计算栈的任何层上被运行-数据库处理器、web应用程序服务器或桌面。这一点只不过是通过在调用集储/过滤操作(一个连接的KnOS等价物)之前将选择中获得的项目传递给指定的处理位置来完成的。在图21的例子中，集储/过滤已经被交付给了web应用程序服务器。
由于每个项目是用一个原始的粒度级别被封装的，因此数据场可以散布在任何数目个数据服务器上，不会增加争用。此外，由于磁盘安排中不需要顺序，因此可以根据每个服务器的请求配置来跨数据服务器安排项目，以平衡工作量。字典服务器{1，1，2，0}是{1，1，1，0}的一个复制的标签集合，其中复制被KnOS订阅服务所维护。可能存在任何数目个字典服务器以平衡工作量。
这是处理节点的一个松散耦合的群集。在节点之间不要求共享的存储器。对合作处理的所有要求都是严格基于简单的、被引用的取出。从而高速总线上的所有通信量或者是HTTP，或者是被引用的取出。所有数据被内嵌在收藏于数据服务器上的一个或多个项目中(没有辅助数据仓库)。所有必不可少的服务器，例如web应用程序服务器、字典服务器和数据服务器，可以根据需要被扩展以满足工作量。唯一的不易扩展的被争用的资源是主总线。
可以用并行处理技术在单个环境内缩放KnOS结构以满足任何企业计算需要，并且可缩放性在安装的整个生存期都是适用的。多个KnOS环境可以在相似的合作的基础上运行。
关联操作的可缩放性：
KnOS数据库处理器本质上可以从处理器获得100％的利用，因为KnOS数据库操作只使用被封装的整数算数。例如考虑被称为集储的基本关联操作。基本集储操作取出两个不同项目的VK集合的两个完全被封装的分类，并且通常用一个布尔AND操作确定矢量键的两个阵列之间的交点。例如，从项目A中选择VK集合的“孩子”分类，从项目B中选择VK集合的“父亲”分类。在两个阵列上执行基本的集储操作将会确定A的孩子或B的父亲，这取决于个人的取向。从而该操作标识了一个特定的情境的两个项目之间的关联的完整范围(在此例中情境＝“父亲/孩子”)，这就是为什么它是一个关联DBMS的核心操作的原因。
对于每个项目，KnOS的首选实施例在每个矢量键维度中以正确的顺序保存VK集合。例如，在“父亲”分类内矢量键{0，3，2，4}在储存介质上可能出现在{0，3，1，4}之后但在{0，3，2，7}之前。基本集储操作比较以这种方式安排的这种矢量键的两个阵列，以确定两个项目的VK集合的交点。以下讨论假定单个项目上的VK集合的单个分类由唯一的条目组成。单个项目的VK集合的单个分类可能具有一个特定矢量键的多个拷贝，但是那是以下的操作讨论的一个无关紧要的变体。
在被集储的两个引用分类中，具有最少数目的矢量键的阵列被称为“驱动器”阵列，而具有较多矢量键的阵列被称为“目标”阵列。以驱动器阵列中的最低(例如{0，0，1，0})矢量键条目开始，集储功能通过一个标准二叉树搜索在目标阵列中查找一个匹配矢量键。如果一个矢量键匹配作为二叉树搜索的一个结果被找到，则矢量键的一个拷贝被插入解答集合，它表示VK集合的交点，并且目标阵列中下一条目的位置被注释出来以便用于搜索的下一次迭代中。如果没有找到目标中的匹配，则目标阵列中的正好大于当前驱动器矢量键的条目的位置被注释出来以便用于下一次迭代中。
对于特定集储操作中的连续二叉树搜索，目标阵列中被注释出的位置之前的部分可以被忽略，因为目标阵列中的该部分中的所有矢量键都小于来自驱动器阵列的正在被处理的当前条目。这一点优化了二叉树搜索。集储操作用驱动器阵列中的每个下一个条目以这种方式继续，直到驱动器阵列中的所有矢量键都已经相对目标阵列被检查。此优化后的二叉树搜索被以下事实进一步优化：实际中，矢量键的VK集合阵列通常包含一个特定情境的矢量键的长字符串。从而，二叉树搜索可以仅在矢量键的项目成分上执行“加载和比较”操作的“比较”部分，仅当找到一个项目匹配时才检查{E，R，C，I}的E、R和C成分。
按照上述方式被优化后，每一个都带有有序的矢量键的两个VK集合阵列可以为每个“驱动器”条目平均约10个优化后的二叉树搜索-对于最初的驱动器条目搜索较多，而对于较靠后的驱动器条目搜索较少-以检查“目标阵列”看是否有匹配。每个二叉树搜索操作是对处理器的一个“加载和比较”操作。如果处理器的流水线被优化，每个“加载和比较”操作可以在单个时钟周期内完成。
即使这些优秀的性能数字也可以被显著“调整”，其方式是通过认识到带有许多矢量键的单个VK集合分类的一个项目很可能包含多个未解决的情境。为了获得最佳性能，应当通过分类这些混合的情境并且将它们分割为独立的标签集合项目来解决这些混合的情境中的每一个。如果要根据情境将一个大VK集合分割成恰好四个独立的标签集合，则进行集储操作所需要的时间将只消耗处理器资源的四分之一。这是因为所有KnOS数据库事务都是对情境敏感的。通过从数据库定义中消除混乱的情境，KnOS为了实现相同结果将要经历的处理工作量会少得多。
例如，考虑一个按照工作负荷号码、按照劳动力类别、按照个人、按照周进行劳动力计划的应用程序。在一个用于10,000员工的较大的企业实现中，此KnOS数据库可能包含一百万个与“40”小时相关联的矢量键。如果“40”项目在单个分类方案中具有这些矢量键，则它可能会提出一个性能问题。如果是这样的话，则可能为“40”项目的VK集合建立一个“个人”情境，以便每个个人将具有其自己的、由其个人的“40”矢量键组成的标签集合。从而，10,000个个性化的标签集合中的每一个对于“40”项目可能平均起来只有100个矢量键引用，而不是一百万个。对于已知个人的数据库事务，这可能按10,000/1的因子加速事务处理。通过检查应用程序的实际工作量配置，可以按照“情境”将VK集合分割成标签集合以提高数据库的性能，从而充分提高其操作效率。
KnOS的超高可缩放性配置存在于六个概念之上。
KnOS在事务间的争用不显著增长的情境下支持非常广泛的分布/并行化，这是因为它的以下能力：a)以非常低级别的粒度完全封装数据；以及b)完全封装核心关联操作。
在任何计算资源可用的地方，既可以水平地跨执行相同的功能的处理器地也可以垂直地在结构栈中上上下下地分布和并行化KnOS关联操作。代表DBMS工作的99％的核心矢量键集储操作可以在一个(或多个)字典服务器、一个(或多个)数据服务器、一个或多个web应用程序服务器或终端用户的PC上被执行。
KnOS关联操作只不过是整数算数，它可以被分阶段并且流水线化，以便对一个处理器实现基本上100％的利用。
按照每个终端用户事务所需要的处理器时间测量的KnOS操作效率可以在实现后被纠正，以便通过标识每个瓶颈的正确“情境”然后按照情境将VK集合分割到专用标签集合中来消除任何瓶颈。所有KnOS瓶颈都涉及带有过度广泛或混乱的情境的VK集合的群集。
KnOS不必为了用户会话的连续性保存中间结果，因为它的效率足够高到能够每次重复处理。假设不需要用每个用户的中间结果在任何系统服务器保持开放会话，则HTTP调度可以以最小的工作负载把事务发到服务器。
最后，由于每个KnOS情境本质上是一个第二键索引，因此一个KnOS实现的工作量配置不取决于被执行的事务的类型或复杂度。
KnOS是高度可缩放的，因为不论是数据或操作，都可被分解为相对小的、被完全封装的成分，这些成分可以用非常有限的系统资源争用被并行化。此外，因为KnOS设计，每个不同类型的事务向处理器提出的工作量配置几乎相同。通过用标签集合改进数据库的情境(分类方案)，可以对KnOS进行性能调整以便每个事务只需要浏览一个有关情境内的数据。
模糊关联：
对于计算发展至关重要的一个主题是模糊(fuzzy)逻辑。没有处理模型比KnOS更适于促进以模糊逻辑构造的应用程序。
关于计算机的许多批评的出现都是因为计算机通常使用精确逻辑。当一台计算机比较“Paco Verde”和“Paul Green”时，它没有检查到匹配。当一台计算机将“1028 Morningside Way”与“1028Mornignside Way”相比较时，它没有检查到匹配。当指示一台计算机“Paco Verde”住在“1028 Morningside Way”而“Paul Green”居住于“1028 Mornignside Way”时，计算机还是不会检查到任何匹配模式。大多数人类会立即发现这些匹配-数据实例分别是西班牙语和英语的，它们是相同的，而地址是彼此的误拼写。这些是一个模糊维度上的匹配。换句话说，通过忽略语言差异和误拼写，计算机将确定“PacoVerde”和“Paul Green”具有一个非常强的关联。它们在语言维度上具有相同的数据实例值，并且它们在误批写维度上住在相同的地址。根据模糊逻辑的一个合理的结论将是“Paco Verde”和“Paul Green”是别名。
由于KnOS是单元模型而不是一个RDBMS，因此特定应用程序能够定义多少个模糊维度，KnOS就能适应、储存和取出多少个模糊维度。例如，应用程序可能为误拼写建立一个模糊维度，而为语义等价建立另一个模糊维度。然后应用程序可以为模糊关联将VK集合插入到KnOS中，就像它为精确关联所做的那样，例如父亲/孩子。当应用程序标识模糊关联时它能够记录它们。这些模糊VK集合可以作为项目内的附加VK集合分类或者作为按照情境的标签集合被包括。通过这种方式，KnOS可以分离维度。当在一个精确情境中被查询时，KnOS在“Paco Verde”和“Paul Green”之间不会找到匹配。在一个模糊语言维度中被查询时，它会找到一个匹配。

Claims (96)

1.一个计算环境中的一个数据管理系统包括：
a.一个以数据实例为中心的结构：
b.其中每个数据实例被封装在一个公共的基本数据结构中；以及
c.其中所述的公共基本数据结构还封装了对相关联的单独被封装的数据实例的引用。
2。权利要求1所述的数据管理系统，其中所述的以数据实例为中心的结构和所述的公共基本数据结构具有结构对称性。
3.权利要求1所述的数据管理系统，其中一个第一数据实例在带有对多个关联的数据实例的多个引用的情况下被封装，并且每一个所述的关联的数据实例在带有对所述的第一被封装的数据实例的一个引用的情况下被单独封装。
4.权利要求3所述的数据管理系统，其中所述的以数据实例为中心的结构和所述的基本数据结构和所述的被封装的数据实例和引用具有结构的和关系的对称性。
5.权利要求1所述的数据管理系统，其中一个第一数据实例在带有对多个相关联的数据实例的多个引用的情况下被封装，并且每一个所述的相关联的数据实例在带有对所述的第一被封装的数据实例的一个引用的情况下被单独封装；
其中每一个所述的被封装的引用是一个逻辑索引，其唯一标识每一个所述的相关联的被封装的数据实例、并且还编码每一个所述的相关联的被封装的数据实例的位置；
并且所述的逻辑索引是“m”个维度的，并且每个维度中具有“n”个比特。
6.权利要求5所述的数据管理系统，其中所述的以数据实例为中心的结构和所述的基本数据结构；和所述的被封装的数据实例和引用具有结构的、关系的、值的和容量的对称性。
7.权利要求1所述的数据管理系统，其中
所述的被封装的引用在至少一个维度中；并且
所述的至少一个维度中的每一个维度对应于一种类型的关联。
8.权利要求7所述的数据管理系统，其中所述的至少一个维度中的每一个维度具有多个所述的被封装的引用。
9.权利要求1所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
10.权利要求2所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
11.权利要求3所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
12.权利要求4所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
13.权利要求5所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
14.权利要求6所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
15.权利要求7所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
16.权利要求8所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
17.权利要求1所述的数据管理系统，其中所述的被封装的引用中至少一个引用是对另一个计算环境中的一个被封装的数据实例的一个引用。
18.权利要求1所述的数据管理系统，其中所述的被封装的数据实例中至少之一的所述的被封装的引用是唯一的，并且所述的被封装的数据实例中至少两个的所述的被封装的引用是大体上相同的。
19.权利要求1所述的数据管理系统，其中所述的以数据实例为中心的结构包括多个预先存在的被封装的数据实例，并且所述的多个预先存在的被封装的数据实例已经建立了关联，并且至少一个新的被封装的数据实例与所述的预先存在的被封装的数据实例中至少之一相关联。
20.权利要求1所述的数据管理系统，其中：
所述的以数据实例为中心的结构包括多个预先存在的被封装的数据实例；所述的被封装的数据实例已经建立了关联；并且其中所述的预先存在的被封装的数据实例中的任何一个可以被删除与其他预先存在的相关联的被封装的数据实例解除关联。
21.权利要求1所述的数据管理系统，其中：
所述的以数据实例为中心的结构包括多个预先存在的被封装的数据实例；所述的被封装的数据实例已经建立了关联；其中至少两个预先存在的被封装的数据实例之间的新关联可以被添加。
22.权利要求1所述的数据管理系统，其中：
所述的以数据实例为中心的结构包括多个预先存在的被封装的数据实例；所述的被封装的数据实例已经建立了关联；并且其中所述的预先存在的被封装数据实例之间的所述的预先存在的关联中的某些可以被删除。
23.权利要求1所述的数据管理系统进一步包括：
a.根据已知的被封装的数据实例的一个选择标准查找特定的未知的被封装的数据实例，其方式是通过访问表示所述的选择标准的所述已知的被封装的数据实例；
b.访问用表示所述的选择标准的所述已知的被封装的数据实例封装的引用；
c.利用布尔操作比较所述的被访问的被封装的引用，以查找对所述的特定的未知的被封装的数据实例的引用；以及
d.取出所述的特定的未知的被封装的数据实例。
24.权利要求23所述的方法，其中：
a.所述的被封装的引用被体现为多个维度中的逻辑索引；
b.每个所述的维度对应于一种类型的关联；以及
c.所述访问进一步包括从所述选择标准中指定的所述维度访问所述的被封装的引用。
25.权利要求23所述的方法，其中：
所述的被封装的引用是“m”个维度的逻辑索引，每一个唯一标识和编码所述的关联的被封装的数据实例的位置；并且进一步包括通过在所述的“m”个维度的逻辑索引中的至少一个上的布尔操作来过滤所述的被封装的引用。
26.权利要求24所述的方法，其中：
所述的被封装的引用是“m”个维度的逻辑索引，每一个唯一标识和编码所述的关联的被封装的数据实例的位置；并且进一步包括通过在所述的“m”个维度的逻辑索引中的至少一个上的布尔操作来过滤所述的被封装的引用。
27.权利要求23所述的方法，其中所述的布尔操作进一步包括：
在单次操作中导致从所述比较的所述结果中直接排除至少一个被封装的引用的多个基本算术操作符。
28.权利要求24所述的方法，其中所述的布尔操作进一步包括：
在单次操作中导致从所述比较的所述结果中直接排除至少一个被封装的引用的一个基本算术操作符。
29.权利要求25所述的方法，其中所述的布尔操作进一步包括：
在单次操作中导致从所述比较的所述结果中直接排除至少一个被封装的引用的一个基本算术操作符。
30.权利要求26所述的方法，其中所述的布尔操作进一步包括：
在单次操作中导致从所述比较的所述结果中直接排除至少一个被封装的引用的一个基本算术操作符。
31.权利要求1所述的系统其中被封装的数据实例具有一个用户接口的属性。
32.权利要求31所述的系统，其中一个用户接口的所述属性是从用户视图、显示元素和数据访问方法的群组中选出的。
33.权利要求1所述的系统进一步包括搜索所述系统，其中不同的所述被封装的数据实例的所述的被封装的引用被用于导出需要的结果。
34.权利要求33所述的系统，其中不同的所述被封装的数据实例的所述的被封装的引用为了公共性、相似性和差异中的至少一个被比较，以导出对应于所述的需要的结果的引用集合。
35.权利要求34所述的系统，其中不同的所述被封装的数据实例的所述被封装的引用按照一种基于值的顺序被储存，并且为了公共性、相似性和差异中的至少一个被比较，以导出对应于所述的需要的结果的引用集合。
36.权利要求33所述的系统，其中：
一个第一数据实例在带有对相关联的数据实例的引用的情况下被封装，并且每个所述的相关联的数据实例在带有对所述的第一被封装的数据实例的一个引用的情况下被单独封装；
其中每一个所述的被封装的引用是一个逻辑索引，其唯一标识每一个所述的相关联的被封装的数据实例、并且还编码每一个所述的相关联的被封装的数据实例的位置；并且
所述的逻辑索引是“m”个维度的，并且每个维度中具有“n”个比特；
通过为了公共性、相似性和差异中的至少一个进行比较以导出对应于所述的需要的结果的引用集合，不同的所述被封装的数据实例的所述被封装的引用被使用。
37.权利要求33所述的系统：
所述的至少一个维度中的每一个维度具有多个所述的被封装的引用；并且不同的所述被封装的数据实例的所述被封装的引用以一种基于值的顺序被储存，并且为了公共性、相似性和差异中的至少一个被比较以导出对应于所述的需要的结果的引用集合。
38.权利要求33所述的系统，其中比较是并行完成的，其中利用了一种硬件装置，所述装置包括作为连到所述的计算环境中的一个存储器总线的一个端口的、比较器连接的移位寄存器阵列。
39.权利要求38所述的系统进一步包括利用一种硬件装置，所述装置包括逻辑电路以及确定搜索结果的移位寄存器的一个连接序列。
40.权利要求1所述的系统进一步包括表示ASCII字符的被封装的数据实例；
包含表ASCII字符的所述被封装的数据实例的所述公共基本数据结构还包含对包含所述的相应的ASCII字符的被封装的数据实例的被封装的引用；并且
包含所述的相应的ASCII字符的所述被封装的数据实例的所述的公共基本数据结构还包含对表示相应的ASCII字符的所述被封装的数据实例的被封装的引用。
41.权利要求40所述的系统，其中所述的带有一个特定的ASCII字符数据实例的被封装的引用是对包含所述的ASCII字符的其他被封装的数据实例的引用，其基于所述的ASCII字符的位置在所述的被封装的数据实例中所述的ASCII字符出现的顺序。
42.权利要求1所述的系统进一步包括：
所述的被封装的数据实例表示Unicode字符；
包含所述表示Unicode字符的被封装的数据实例的所述公共基本数据结构也包含对包含所述的相应的Unicode字符的被封装的数据实例的被封装的引用；并且
包含所述表示Unicode字符的被封装的数据实例的所述公共基本数据结构也包含对所述的表示相应的Unicode字符的数据实例的被封装的引用。
43.权利要求42所述的系统，其中所述的带有一个特定Unicode字符数据实例的被封装的引用是对包含所述的Unicode字符的其他数据实例的引用，其基于所述的Unicode字符的位置在所述的被封装的数据实例中所述的Unicode字符的出现顺序。
44.权利要求1所述的系统，其中：
所述的被封装的数据实例包含表示任何数据类型的一个标记集合的被封装的数据实例；
包含所述表示任何数据类型的一个标记集合的数据实例的所述公共基本数据结构也包含对包含所述的相应的任何数据类型的标记集合的被封装的数据实例的被封装的引用；并且
包含所述任何数据类型的标记集合的被封装的数据实例的所述公共基本数据结构也包含对所述的表示相应的任何数据类型的标记集合的数据实例的被封装的引用。
45.权利要求44所述的系统，其中所述的任何数据类型的一个特定的标记集合的被封装的引用是对包含所述的任何数据类型的标记集合的其他被封装的数据实例的引用，其基于任何数据类型的标记集合的位置在所述的被封装的数据实例中所述的任何数据类型的标记集合的出现顺序。
46.权利要求45所述的系统，其中：
所述的标记集合是从包含以下成员的群组中选出来的：图形描述符的一个集合、颜色的一个集合、形状的一个集合、字形的一个集合、波形的一个集合、频率值的一个集合、音频频率值的一个集合、符号的一个定义集合以及实数。
47.权利要求1所述的数据管理系统，其中：
a.所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的；
b.根据已知的被封装的数据实例的一个选择标准查找特定的未知的被封装的数据实例，其方式是通过访问表示所述选择标准的所述已知的被封装的数据实例；
c.访问用表示所述选择标准的所述已知的被封装的数据实例封装的引用；
d.利用布尔操作比较所述的被访问的被封装的引用以查找对所述的特定的未知的被封装的数据实例的引用；以及
e.取出所述的特定的未知的被封装的数据实例。
48.权利要求47所述的系统进一步包括搜索所述的系统，其中不同的所述被封装的数据实例的所述被封装的引用被用于导出需要的结果。
49.权利要求1所述的数据管理系统，其中：
所述被封装的引用中的至少一个是对另一个计算环境中的一个被封装的数据实例的一个引用；并且
一个第一数据实例在带有对多个相关联的数据实例的多个引用的情况下被封装，并且每个所述的相关联的数据实例在带有对一个被封装的数据实例的一个引用的情况下被单独封装。
50.权利要求1所述的数据管理系统，其中：
a.所述被封装的数据实例中至少一个的所述被封装的引用是唯一的，并且所述被封装的数据实例中至少两个的所述被封装的引用是大体上相同的；
b.根据已知的被封装的数据实例的一个选择标准查找特定的未知的被封装的数据实例，其方法是通过访问表示所述选择标准的所述已知的被封装的数据实例；
c.访问用表示所述选择标准的所述已知的被封装的数据实例封装的引用；
d.利用布尔操作比较所述的被访问的被封装的引用以查找对所述的特定的未知的被封装的数据实例的引用；以及
e.取出所述特定的未知的被封装的数据实例。
51.权利要求1所述的数据管理系统，其中
所述被封装的数据实例中至少一个的所述被封装的引用是唯一的，并且所述被封装的数据实例中至少两个的所述被封装的引用是大体上相同的；以及
搜索所述的系统，其中不同的所述被封装的数据实例的所述被封装的引用被用于导出需要的结果。
52.一个计算环境中的一个数据管理系统包括：
a.一个以数据实例为中心的结构：
b.其中每个数据实例被封装在一个公共的基本数据结构中；
c.其中所述的公共基本数据结构还封装了对相关联的单独被封装的多个数据实例的多个引用；
d.一个第一数据实例在带有对相关联的多个数据实例的多个引用的情况下被封装，并且每个所述相关联的数据实例在带有对所述的第一被封装的数据实例的一个引用的情况下被单独封装；
e.其中每一个所述被封装的引用是一个逻辑索引，其唯一标识每一个所述的相关联的被封装的数据实例、并且还编码每一个所述的相关联的被封装的数据实例的位置；
f.所述的逻辑索引是“m”个维度的，并且每个维度中具有“n”个比特；并且
g.所述的被封装的多个引用是在至少一个维度中；并且所述的至少一个维度中的每一个维度对应于一种类型的关联。
53.权利要求52所述的数据管理系统，其中所述的公共基本数据结构是独立于应用程序的，并且对于所有所述的数据实例一般都是相同的。
54.权利要求53所述的数据管理系统，进一步包括：
a.根据已知的被封装的数据实例的一个选择标准查找特定的未知的被封装的数据实例，其方法是通过访问表示所述选择标准的已知的被封装的数据实例；
b.访问用表示所述选择标准的所述已知的被封装的数据实例封装的引用；
c.利用布尔操作比较所述的被访问的被封装的引用以查找对所述的特定的未知的被封装的数据实例的引用；以及
d.取出所述的特定的未知的被封装的数据实例。
55.权利要求54所述的系统进一步包括搜索所述系统，其中不同的所述被封装的数据实例的所述被封装的引用被用于导出需要的结果。
56.权利要求55所述的数据管理系统，其中所述被封装的引用中的至少一个是对另一个计算环境中的一个被封装的数据实例的一个引用。
57.权利要求56所述的数据管理系统，其中所述被封装的数据实例中至少一个的所述被封装的引用是唯一的，并且所述被封装的数据实例中至少两个的所述被封装的引用是大体上相同的。
58.权利要求57所述的系统进一步包括搜索所述的系统，其中不同的所述被封装的数据实例的所述被封装的引用被用于导出需要的结果。
59.权利要求52所述的数据管理系统进一步包括：
a.根据已知的被封装的数据实例的一个选择标准查找特定的未知的被封装的数据实例，其方法是通过访问表示所述选择标准的已知的被封装的数据实例；
b.访问用表示所述选择标准的所述已知的被封装的数据实例封装的引用；
c.利用布尔操作比较所述被访问的被封装的引用以查找对所述特定的未知的被封装的数据实例的引用；以及
d.取出所述的特定的未知的被封装的数据实例。
60.权利要求52所述的数据管理系统进一步包括搜索所述的系统，其中不同的所述被封装的数据实例的所述被封装的引用被用于导出需要的结果。
61.权利要求52所述的数据管理系统，其中所述的被封装的引用中的至少一个是对另一个计算环境中的一个被封装的数据实例的一个引用。
62.权利要求52所述的数据管理系统，其中所述的被封装的数据实例中至少一个的所述被封装的引用是唯一的，并且所述的被封装的数据实例中至少两个的所述被封装的引用是大体上相同的。
63.一种在一个以被封装的数据实例为中心的结构中协调物理存储器寻址和逻辑存储器寻址方法，包括：
对应于每个被封装的数据实例，有一个对所述被封装的数据实例的逻辑引用；
在一个第一容器中封装对所述的被封装的数据实例的所述逻辑引用；
用一个物理引用将所述第一容器中的所述逻辑引用相关到一个位置，在该位置所述被封装的数据实例被储存在一个物理储存介质中；
在一个第二容器中封装所述物理引用；以及
用所述的逻辑引用将所述第二容器的所述物理引用相关到所述第一容器中的所述被封装的数据实例。
64.权利要求63所述的方法其中所述的容器是一个基本数据结构。
65.权利要求63所述的方法所述的物理引用是“n”个维度的，维度的数目和每个维度中比特的数目对应于所述的物理储存介质的结构。
66.权利要求65所述的方法，其中利用所述的物理引用计算所述的物理储存介质中的一个地址。
67.权利要求63所述的方法进一步包括：
协调多个数据实例；以及
分别在所述第一和第二容器中封装多个所述逻辑引用和多个所述物理引用。
68.权利要求63所述的方法进一步包括对所述第一容器中的所述多个逻辑引用分类。
69.权利要求68所述的方法进一步包括对所述第二容器中的所述多个物理引用分类。
70.一种在一个具有多个可变长度的数据实例的、以数据实例为中心的结构中管理数据储存的方法包括：
将所述的数据实例大体上顺序地储存在一个物理储存介质中；
将每个数据实例储存在各自被分配的空间中；
更新所述的数据实例之一；
通过确定储存所述的更新后的数据实例所需要的物理空间量将所述的更新后的数据实例结合到所述的物理储存介质中；
当所述的物理空间等于或小于所述的各自被分配的空间时，则将所述的更新后的数据实例储存在所述的各自被分配的空间中；
当所述的物理空间大于所述的各自被分配的空间时，则标识至少一个物理上相邻的、具有等于或大于所述的物理空间和所述的各自被分配的空间之差的一个总分配空间的数据实例；以及
根据所述的相邻数据实例的大小和数目，将所述的更新后的数据实例写入所述的物理储存介质上的一个更新后的位置处。
71.权利要求70所述的管理数据储存的方法进一步包括：
根据所述的相邻的数据实例的大小和数目，将所述的更新后的数据实例写入所述的物理储存介质上的更新后的各自分配的空间中。
72.权利要求70所述的管理数据储存的方法进一步包括：
将所述的至少一个物理上相邻的数据实例移动到一个最后被储存的数据实例之后的位置；以及
将所述的更新后的数据实例写到所述的物理储存介质中所述至少一个物理上相邻的数据实例和所述各数据实例的位置中。
73.权利要求70所述的管理数据储存的方法进一步包括：
将所述的至少一个物理上相邻的数据实例移动到最后被储存的数据实例之后的位置；以及
将所述的更新后的数据实例写到所述的物理储存介质中一个等于所述各自的被分配的空间和所述被移动的至少一个物理上相邻的数据实例的被分配空间的总量的、更新后的分配空间中。
74.权利要求73所述的管理数据储存的方法，其中所述的更新后的分配空间大于所述的更新后的物理实例的所述的物理空间。
75.权利要求70所述的管理数据储存的方法，其中所述的至少一个物理上相邻的数据实例顺序出现在所述的更新后的数据实例之后。
76.权利要求70所述的管理数据储存的方法，其中所述的至少一个物理上相邻的数据实例顺序出现在所述的更新后的数据实例之前。
77.权利要求70所述的管理数据储存的方法，其中所述的至少一个物理上相邻的数据实例顺序出现在所述的更新后的数据实例之前和之后。
78.权利要求70所述的管理数据储存的方法，其中
所述的至少一个物理上相邻的数据实例中无论哪一个具有的被分配空间最接近并且大于所述的物理空间和所述的更新后的数据实例的所述各自被分配的空间之差，该所述至少一个物理上相邻的数据实例被移动到一个最后被储存的数据实例之后的位置；
将所述的更新后的数据实例写到所述的物理储存介质中所述至少一个物理上相邻的数据实例和所述各数据实例的位置中；以及
将所述的更新后的数据实例写到所述的物理储存介质中一个等于所述各自的被分配的空间和所述被移动的至少一个物理上相邻的数据实例的被分配空间的总量的、更新后的分配空间中。
79.权利要求70所述的管理数据储存的方法，其中当所述更新后的数据实例的所述物理空间小于所述的至少一个物理上相邻的数据实例的所述被分配的空间时，则所述更新后的数据实例被移动到一个最后被储存的数据实例之后的位置。
80.权利要求79所述的管理数据储存的方法，其中所述被移动的更新后的数据实例的所述各自分配的空间被添加到顺序出现在所述更新后的数据实例之前的所述的物理上相邻的数据实例的所述的被分配的空间。
81.权利要求70所述的管理数据储存的方法，其中所述的被分配的空间中的至少一个大于各数据实例的大小。
82.一种将一个不以数据实例为中心的数据库转换为一个以数据实例为中心的数据的方法，包括：
在所述的以数据实例为中心的数据库中创建数据实例，其表示所述的不以数据实例为中心的数据库模式的元素和所述的不以数据实例为中心的数据库的数据元素；以及
在所述的以数据为中心的数据库中的所述的数据实例之间创建关联，其表示所述不以数据实例为中心的数据库的数据元素和所述的模式元素之间的关系。
83.权利要求82所述的方法，其中所述的转换是通过一个软件代理，所述软件代理是所述的以数据实例为中心的数据库中的一个数据实例。
84.权利要求82所述的方法，其中所述的不以数据实例为中心的数据库包括一个平面文件。
85.一个数据管理系统包括：
一个或多个项目；
其中每个所述的项目封装一个数据实例；以及
其中彼此相关联的项目封装彼此之间的相互引用。
86.权利要求85所述的数据管理系统，其中每个所述的项目被表示在一个基本数据结构中。
87.权利要求85所述的数据管理系统，其中每个所述的项目具有一个与之相关联的唯一引用。
88.权利要求87所述的数据管理系统，其中所述的唯一引用也用作一个索引，以便物理地定位与每个所述的项目相关联的所述数据实例。
89.权利要求85所述的数据管理系统，其中所述对相关联的项目的引用被安排在集合中，其定义所述项目和所述集合中引用的每个其他项目之间的关联的类型。
90.权利要求87所述的数据管理系统，其中每个所述的引用是一个“m”维度的索引，每个所述的维度长度为“n”个比特。
91.权利要求90所述的数据管理系统，其中“m”为4而“n”为30。
92.权利要求85所述的数据管理系统，其中所述项目可充当一个或多个其他成员项目的容器。
93.权利要求92述的数据管理系统，其中一个项目在一个容器项目内的成员资格是由所述容器项目和每个所述成员项目的所述逻辑索引中、所述的“m”个维度中的一个或多个维度中的一个身份所指示的。
94.权利要求85所述的数据管理系统，其中所述每个所述项目可以封装内嵌元素。
95.权利要求94所述的数据管理系统，其中所述内嵌元素是对其他项目的引用。
96.权利要求85所述的数据管理系统，其中所述的数据实例可包含任何类型的数据。
CN038227444A 2002-07-26 2003-07-16 使用参考与一般数据项关联的数据管理结构 Expired - Fee Related CN1856783B (zh)

Applications Claiming Priority (5)

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

Publications (2)

Publication Number Publication Date
CN1856783A true CN1856783A (zh) 2006-11-01
CN1856783B CN1856783B (zh) 2011-05-25

Family

ID=31498594

Family Applications (1)

Application Number Title Priority Date Filing Date
CN038227444A Expired - Fee Related CN1856783B (zh) 2002-07-26 2003-07-16 使用参考与一般数据项关联的数据管理结构

Country Status (13)

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

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102831217A (zh) * 2012-08-17 2012-12-19 安科智慧城市技术（中国）有限公司 一种数据处理方法及装置
CN101727478B (zh) * 2008-10-23 2013-06-05 国际商业机器公司 动态建立并用储存库中的数据填充数据集市的方法和系统
CN103793451A (zh) * 2012-10-26 2014-05-14 国际商业机器公司 用于排序并表示数据元组集合的系统和方法
CN103955526A (zh) * 2014-05-09 2014-07-30 中国联合网络通信集团有限公司 数据存储方法和装置
CN104714999A (zh) * 2013-12-16 2015-06-17 国际商业机器公司 整合来自多个源的时间感知的数据的系统和方法
CN105956012A (zh) * 2016-04-21 2016-09-21 哈尔滨工程大学 基于图划分策略的数据库模式抽象方法
CN106682030A (zh) * 2015-11-10 2017-05-17 阿里巴巴集团控股有限公司 信息处理方法及装置
CN108701075A (zh) * 2016-12-21 2018-10-23 株式会社岩崎电机制作所 数据表格创建装置、数据表格创建方法以及数据表格创建程序
CN109564577A (zh) * 2016-08-03 2019-04-02 微软技术许可有限责任公司 对数据实例的高效去规范化
CN110765159A (zh) * 2019-11-01 2020-02-07 上海达梦数据库有限公司 对象解析方法、装置、存储介质及设备
CN111143353A (zh) * 2019-12-04 2020-05-12 中国航空工业集团公司西安飞行自动控制研究所 更改单中提取bom变化数据的方法
CN114579553A (zh) * 2022-03-07 2022-06-03 中国标准化研究院 一种数据质量保证方法

Families Citing this family (99)

* 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
US7464074B2 (en) * 2002-11-13 2008-12-09 Danny Sebbane Method and system for using query information to enhance catergorization 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
US8869061B1 (en) 2003-08-29 2014-10-21 Microsoft Corporation User interface for searching an electronic document
US7337176B1 (en) * 2003-08-29 2008-02-26 Sprint Communications Company L.P. Data loading tool for loading a database
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
US7836083B2 (en) * 2004-02-20 2010-11-16 Factiva, Inc. 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
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
US7627591B2 (en) 2004-10-29 2009-12-01 Skyler Technology, Inc. Method and/or system for manipulating tree expressions
US7636727B2 (en) 2004-12-06 2009-12-22 Skyler Technology, Inc. Enumeration of trees from finite number of nodes
US7630995B2 (en) * 2004-11-30 2009-12-08 Skyler Technology, Inc. Method and/or system for transmitting and/or receiving data
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
US7571192B2 (en) * 2005-06-15 2009-08-04 Oracle International Corporation Methods and apparatus for maintaining consistency during analysis of large data sets
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
FR2888967B1 (fr) * 2005-07-25 2008-05-09 Airbus Sas Procede et systeme de modelisation d'une interface entre un utilisateur et son environnement a bord d'un vehicule
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
EP2212816A1 (en) * 2007-10-01 2010-08-04 Microsoft Corporation Integrated genomic system
US8190646B2 (en) * 2008-01-02 2012-05-29 International Business Machines Corporation Associative object model for composite entity information
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
US9430550B2 (en) 2012-09-28 2016-08-30 Oracle International Corporation Clustering a table in a relational database management system
US8996544B2 (en) 2012-09-28 2015-03-31 Oracle International Corporation Pruning disk blocks of a clustered table in a relational database management system
US9514187B2 (en) 2012-09-28 2016-12-06 Oracle International Corporation Techniques for using zone map information for post index access pruning
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
US9613112B2 (en) 2013-03-15 2017-04-04 Miosoft Corporation Structuring data
US10642837B2 (en) 2013-03-15 2020-05-05 Oracle International Corporation Relocating derived cache during data rebalance to maintain application performance
US9665403B2 (en) 2013-03-15 2017-05-30 Miosoft Corporation Executing algorithms in parallel
CN103577590A (zh) * 2013-11-12 2014-02-12 北京润乾信息系统技术有限公司 一种数据查询方法和系统
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
ES2728680T3 (es) 2015-01-31 2019-10-28 Inexto Sa Identificación y verificación seguras de productos
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
WO2017031459A1 (en) * 2015-08-19 2017-02-23 Integrator Software Integrated software development environments, systems, methods, and memory models
US10594494B2 (en) 2015-08-25 2020-03-17 Inexto Sa Multiple authorization modules for secure production and verification
US10579889B2 (en) 2015-08-25 2020-03-03 Inexto Sa Verification with error tolerance for secure product identifiers
US10235406B2 (en) 2015-12-15 2019-03-19 Microsoft Technology Licensing, Llc Reminder processing of structured data records among partitioned data storage spaces
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
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
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
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 侍意(厦门)网络信息技术有限公司 对有关联性对象的数据的存储结构及方法、检索和可视化展示方法

Family Cites Families (83)

* 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
JPH0195324A (ja) * 1987-10-07 1989-04-13 Ricoh Co Ltd データベース管理システムの拡張機構
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
JPH06332710A (ja) 1993-05-21 1994-12-02 Fujitsu Ltd オブジェクト指向データ処理システム
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
WO1995002222A1 (en) 1993-07-07 1995-01-19 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
ATE195383T1 (de) 1994-05-10 2000-08-15 Siemens Ag 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 オブジェクト指向データベース管理装置
US5878408A (en) 1996-12-06 1999-03-02 International Business Machines Corporation Data management system and process
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
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 データベース問い合わせ方法及びその実施装置並びにその処理プログラムを記録した媒体
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
EP1125226A4 (en) 1998-09-30 2006-05-10 I2 Technologies Inc Multi-dimensional data management system
JP2000112797A (ja) 1998-10-02 2000-04-21 Nippon Telegr & Teleph Corp <Ntt> ビューディレクトリ処理方法および装置とビューディレクトリ処理プログラムを記録した記録媒体
US6185555B1 (en) 1998-10-31 2001-02-06 M/A/R/C Inc. Method and apparatus for data management using an event transition network
US6029174A (en) 1998-10-31 2000-02-22 M/A/R/C Inc. Apparatus and system for an adaptive data management architecture
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
WO2003040957A1 (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

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101727478B (zh) * 2008-10-23 2013-06-05 国际商业机器公司 动态建立并用储存库中的数据填充数据集市的方法和系统
CN102831217A (zh) * 2012-08-17 2012-12-19 安科智慧城市技术（中国）有限公司 一种数据处理方法及装置
CN102831217B (zh) * 2012-08-17 2015-03-04 安科智慧城市技术（中国）有限公司 一种数据处理方法及装置
CN103793451B (zh) * 2012-10-26 2017-11-03 国际商业机器公司 用于排序并表示数据元组集合的系统和方法
CN103793451A (zh) * 2012-10-26 2014-05-14 国际商业机器公司 用于排序并表示数据元组集合的系统和方法
CN104714999B (zh) * 2013-12-16 2018-04-27 国际商业机器公司 整合来自多个源的时间感知的数据的系统和方法
CN104714999A (zh) * 2013-12-16 2015-06-17 国际商业机器公司 整合来自多个源的时间感知的数据的系统和方法
CN103955526B (zh) * 2014-05-09 2017-05-10 中国联合网络通信集团有限公司 数据存储方法和装置
CN103955526A (zh) * 2014-05-09 2014-07-30 中国联合网络通信集团有限公司 数据存储方法和装置
CN106682030A (zh) * 2015-11-10 2017-05-17 阿里巴巴集团控股有限公司 信息处理方法及装置
CN105956012A (zh) * 2016-04-21 2016-09-21 哈尔滨工程大学 基于图划分策略的数据库模式抽象方法
CN105956012B (zh) * 2016-04-21 2019-04-23 哈尔滨工程大学 基于图划分策略的数据库模式抽象方法
CN109564577A (zh) * 2016-08-03 2019-04-02 微软技术许可有限责任公司 对数据实例的高效去规范化
CN109564577B (zh) * 2016-08-03 2023-06-09 微软技术许可有限责任公司 对数据实例的高效去规范化
CN108701075A (zh) * 2016-12-21 2018-10-23 株式会社岩崎电机制作所 数据表格创建装置、数据表格创建方法以及数据表格创建程序
CN110765159A (zh) * 2019-11-01 2020-02-07 上海达梦数据库有限公司 对象解析方法、装置、存储介质及设备
CN110765159B (zh) * 2019-11-01 2022-08-12 上海达梦数据库有限公司 对象解析方法、装置、存储介质及设备
CN111143353A (zh) * 2019-12-04 2020-05-12 中国航空工业集团公司西安飞行自动控制研究所 更改单中提取bom变化数据的方法
CN111143353B (zh) * 2019-12-04 2023-04-14 中国航空工业集团公司西安飞行自动控制研究所 更改单中提取bom变化数据的方法
CN114579553A (zh) * 2022-03-07 2022-06-03 中国标准化研究院 一种数据质量保证方法

Also Published As

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

Similar Documents

Publication Publication Date Title
CN1856783A (zh) 使用参考与一般数据项关联的数据管理结构
Tang et al. Data mining with SQL Server 2005
CN1182467C (zh) 可扩充的分布企业应用集成系统
CN1262958C (zh) 使用元数据在关系数据库中创建多维数据集的方法和系统
US7831632B2 (en) Method and system for reconstruction of object model data in a relational database
US20130275420A1 (en) Computer-Implemented System And Method For Conducting A Document Search Via Metaprints
CN1726495A (zh) 规定用于关系olap引擎的多维计算
CN1292901A (zh) 数据库设备
CN1839403A (zh) 经改进的慈善管理系统和商务方法
CN1820266A (zh) 用于将应用程序与基于项的存储平台接口的系统和方法
CN1535429A (zh) 可重用数据标记语言
CN1820245A (zh) 用于基于项目的存储平台中的数据建模的系统和方法
CN1585945A (zh) 用于将xml模式映射到对象关系数据库系统的机制
CN1882943A (zh) 使用超单元的搜索处理的系统和方法
CN1578949A (zh) 数据对象导向的储存系统
de la Vega et al. Mortadelo: Automatic generation of NoSQL stores from platform-independent data models
US8200668B2 (en) Scalar representation for a logical group of columns in relational databases
CN101040250A (zh) 数据处理装置和数据处理方法
CN101031872A (zh) 数据处理装置和数据处理方法
CN1828594A (zh) 对象关系型数据的数据模型
CN1871598A (zh) 用于可由硬件/软件接口系统管理的信息单元的扩展和继承的系统和方法
CN1739093A (zh) 同步模式的实现系统
CN1716247A (zh) 对可由硬件/软件接口系统进行信息管理的单元的对等同步化提供冲突处理的系统和方法
Manivannan et al. Artificial intelligence databases: turn-on big data of the SMBs
Hovy et al. Data Acquisition and Integration in the DGRC's Energy Data Collection Project

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1098842

Country of ref document: HK

C14 Grant of patent or utility model
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: GR

Ref document number: 1098842

Country of ref document: HK

CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20110525

Termination date: 20210716

CF01 Termination of patent right due to non-payment of annual fee