大型共享数据库的数据关系模型E.F.CoddIBM Research Laboratory,SanJose,California未来的数据库使用者一定是和数据在机器中的存储（即数据库的内部模式）相隔离的。
而通过提示服务来提供信息是一个不太令人满意的解决方法。
当数据的内部模式表示发生改变，甚至数据内部表示的多个方面发生改变时，终端用户和大多数应用程序的活动都不会受到影响。
因此，查询、更新和报告存储信息类型的自然增长和变动都需要在数据表示中表现出来。
现存的不可推断的、格式化的数据系统给用户提供了树结构的文件或者更一般的网格模式的数据。
本文在第一部分讨论这些模式的不足之处。
并且会介绍一种基于n元组关系的模式，一种数据库关系的正式形式和通用数据子句的概念。
第二部分将讨论一些关系的操作（不是逻辑层面的），并且把这些操作应用于用户模式上解决冗余和一致性问题。
1关系模式和一般模式1.1简介这篇文章是关于系统的基本关系原理的应用，这个原理提供了共享大型格式化数据库的方法。
除了Childs[1]的文章有介绍外，用于数据库系统的关系的主要应用还表现在演绎推理型的问-答系统中。
Levein和Maron[2]提供了大量关于这个领域的参考资料。
相比之下，这里要解决的问题是一些数据独立性的问题——应用程序和终端活动之于数据类型增长和数据表示变动的独立性，而数据一致性问题即使在非演绎推理型系统中也是很棘手的。
在目前流行的非推论性系统中，第一部分要介绍的数据的关系视图（或叫做模式）在一些方面似乎优于图模式和网格模式[3,4]。
这种模式提供了一种根据数据的自然结构来描述描述数据的方式——也就是说，不用为了数据的机器表示而添加其他的将结构。
因此，这种模式为高水准的数据语言提供了基础，而这种数据语言机制一方面可以达到最大化程序之间的独立性，另一方面也可以最大化数据的机器表示和组织之间的独立性。
关系模式更高一级的优势在于它构成了关系处理可导性、冗余性和一致性的坚固基础——这些将在第二部分讨论。
另一方面，网络模型产生了一些混淆，尤其是把连接的源误作为关系的源（见第二部分“连接陷阱”）最后，关系视图允许对目前格式化数据系统的范围和逻辑限制的更清晰的估算，并且有在单独的系统内竞争数据表示方式的优点（从逻辑的观点）。
更清楚的这个观点的示例会在本文中的不同部分中被阐释。
但是支持关系模式的系统实现不会讨论。
1.2目前系统的数据相关性最近发展的信息系统中数据描述表的提供是向数据独立性目标[5,6,7]靠近的重要提高。
这些表可以使改变数据库中数据表示的某些特征变得更容易些。
但是，许多数据表示特征可以在不逻辑地削弱一些应用程序的情况下被改变的功能仍受到相当的限制。
更进一步，与用户交互的数据模式仍然有一些散乱的代表性特征，特别是关于数据收集的描述（如个人名目）。
三个仍然需要提高的数据独立性的主要类型是：排序依赖，索引依赖和存取路径的依赖。
在一些系统中这些依赖之间并不是明确分隔的。
1.2.1顺序依赖。
数据库中的数据元素可以有很多种存储方式，一些是不考虑顺序的，一些是允许一个元素只参与一个排序，而另外一些允许每个元素参与多个排序。
现在让我们来看看要求或允许数据元素存储在至少一个总排序的现存系统，而这种总体排序是与硬件决定的排序地址密切相关的。
这种系统通常允许应用程序自己假定文件记录的表示顺序与其在磁盘上的存储顺序是相同的（或者说是存储排序的子目）。
这些运用文件存储顺序有利条件的应用程序，如果由于某些原因而变得需要用一个新排序替换这种顺序时，很可能不能正确运行。
以指针方式实现的存储排序也有相似的问题。
我们没有必要挑选出任何一个系统作为例子，因为现在上市的所有著名的信息系统在清楚区别表示顺序和存储顺序两方面都是失败的。
重要的实现问题必须得到解决来提供这种独立性。
1.2.2索引依赖。
格式化数据的上下文联系中，索引通常被看成数据表示的一个纯粹的效能导向组件。
它倾向于提高对查询和更新的响应，同时减慢了对插入和删除的响应。
从信息的观点来看，索引是数据表示的冗余构成成分。
如果一个系统王全用索引，并且如果它在变化活动形式的数据库环境中能够表现的很好，那么不时地产生和销毁索引的能力可能是必须的。
那么问题产生了：应用程序和终端活动在索引项来去的时候仍然能够不受影响吗？目前格式化数据系统采用很不相同的方法来进行索引。
TDMS[7]无条件地提供了所有属性上的索引。
IMS[5]目前发布的版本为用户提供了为每一文件选择的权利：是完全没有索引（层次序列的组织）和只有主键索引（层次化索引序列组织）之间的选择。
没有一种会使用户的应用逻辑依赖于无条件提供的索引的存在。
但是，IDS[8]允许文件设计者选择用于索引的属性和指定用于与索引通过外加链的方式组合成文件结构的属性。
运用索引链性能的优势的应用程序必须通过名字来引用这些链。
如果这些链后来被删除，那么这些程序就无法正确运行。
1.2.3存取路径依赖。
许多现存格式化数据系统为用户提供了树结构的文件或者更一般的数据网络模式。
为和这类系统共同工作而发展的应用程序，在树或网格的结构改变时，往往会在逻辑层受到削弱。
一个简单的例子如下。
设想数据库包含关于部件和工程的信息。
对于每一个部件，其部件号码、部件名字、部件描述、在手的数量和订单上的数量的信息都被记录。
对于每一个工程，其工程编号、工程名字和工程描述信息被记录。
无论什么时候，一个工程要用特定部件时，用于这个工程的那种部件的数量也会被记录。
假如系统要求用户或者文件创作者根据树结构声明或者定义数据。
那么，任一层次结构都可以用到如上提到的信息上（见结构1——5）。
现在考虑打印用于名为“alpha“的工程每个部件的编号、部件名和数目。
不考虑可用于面向树的信息系统可以用于解决这个问题，我们可以得到以下的发现。
如果程序P是开发用于解决这个问题（假设结构是上面五种结构中的一种），也就是说P不会检测哪一种结构对他来说有效，然而这样的结果是P至少在其中三个结构上是失败的。
更具体地，如果P对结构5行之有效，那么在其他结构上就会失败；如果P对结构3或4行之有效，那么它至少会在结构1,2,5上是失败的；如果P对结构1或2行之有效，那么它至少会在结构3,4,5上是是小的。
对于每一种情况的原因都很简单。
在没有经过检测来决定哪种结构是有效的情况下，P会失败是因为它试图引用一个不存在的文件（现可用的系统把这种情况视为error）或者是它没有引用包含它必需信息的文件。
有疑问的读者应该找一些样例程序来理解这个简单的问题。
由于在一般情况下，开发可以检测系统允许的所有树结构的应用程序是不实际的，而且这种程序在结构需要改变时也会失败。
为用户提供网格数据模式的系统也会遇到相似的问题。
在树和网格两种情形下，用户（或者是用户的程序）都被要求采用用户数据存取路径的集合。
这些路径是否与存储表示的指针定义的路径有较近通信是没有影响的，而在IDS中这种通信时极其简单的，但在TDMS中就正好相反了。
不考虑存储表示来看这种问题，结果就是，终端活动和程序变得依赖于用户存取路径的连续存在性。
对于这个问题的一个解决方案就是采用如下策略：一旦用户存取路径被定义了，那么除非所有应用这个路径的所有程序都废弃了（finish了），否则这个路径就不会过时。
由于在团体总体模式的数据库用户的存取路径的数量最终可能变得过大，因此这种策略是不实际的。
1.3数据的关系视图关系这个词在这里使用的是其被广泛认可的数学意义。
给定集合S1,S2,……,Sn（这些集合没有必要一定是不同的），如果R是一个满足如下条件的n元组集合：其每个元素的第一个元素来自S1，第二个元素来自集合S2，以此类推，那么R就是这n 个集合（S1,S2,……,Sn）上的一个关系。
我们用Sj来表示R的第j个域。
正如上面所定义，R被称作是n级的。
1级的关系通常叫做一元关系，2级的被叫做二元关系，3级的被叫做三元关系，而n级的叫n元关系。
（更简单地说，R是S1,S2,……,Sn这n个集合的笛卡尔乘积的一个子集）说明一下，我们将频繁地使用关系的数组表示，但是必须清楚的是这个特定表示并不是用于解释关系视图必须的部分。
用于表示n元关R的数组有如下特征：（1）每一行代表R的一个n元组（2）行的排列顺序是无关紧要的（3）所有行都是不相同的（4）列的顺序是有意义的——列应该符合R定义时的域的顺序S1,s2,……,Sn（但是注意，排序的域和无序的域下标之间的关系）（5）每个列的意义部分是由命名相应域来传达的图1中的例子展示了一个叫做supply 4级的关系，这个关系显示的是特定工程的特定供应者的特定数量的零件发货过程。
图1有人可能会问：如果列由相应域的名字来标识，那么为什么列的顺序会有影响呢？正如图2中例子显示的一样，两列可以有相同的头（表示同样的域），但是对于这个关系他们有不同的含义。
这里描述的关系叫做component。
它是一个三元关系，其中前两个域叫做part而第三个域叫做quantity。
Component（x，y，z）的意思就是部件x部件y的直接构成成分（或者子部件），而需要z个的x部件来组成一个的y部件。
这个关系在零件扩大问题中有重要作用。
图2一个引人注目事实是，一些现存的信息系统（主要是基于树结构文件组织）不能够为有两个或两个以上的相同域的关系提供有效地数据表示。
IMS/360[5]的目前版本就是这种系统的一个实例。
一个数据库中的总体数据可以看做一个随着时间变化的关系的集合。
这些种类的关系有各种各样的级（或度）。
随着时间的前进，每个n元关系都可能经历插入另外的n元组，删除现存的n元组和改变现存任意n元组的组成部分的操作。
但是，在很多商业、政府和科学数据库中，一些关系的度（或作级别）是相当高的（30级的关系也是很常见的）。
用户通常不能记住任何关系的所有域的顺序（例如，关系supply中定序的提供者、零件、工程和数量）。
因此，我们提出用户不必处理域排序的关系，而处理与其非排序域的有同样效果的关系的方法。
为了达到这个目的，关系中的域必须是在不采用位置时唯一可确认的，至少在某个给定的关系中是这样的。
因此，在有两个或更多相同域的地方，我们要求对每一种情况下域名都是合格的不同的角色名（rol e name），这些角色名用于识别给定的关系中的域所扮演的角色。
例如，在图2的component关系中，第一个域part可以用合格角色名sub指示，而第二个用super，以便用户能够处理component关系和它的域——sub.partsuper.part,quantity——而不用考虑这些域之间的任何排序。
总之，提出多数用户应该与由随时间变化的联系集合（而不是关系）组成的数据的关系模式交互。
