图灵奖得主的得奖论文大型的共享数据银行的数据的一个关系模型第2部分

1.2.3存取路径依赖
许多的现有的格式化的数据系统给用户提供了树形结构的文件，或者是
数据的稍微更加通用化一点的网络模型。如果在结构上这些树或者是网络模型被改变，工作在这些系统上的已开发的应用程序能被逻辑性的损害。一个简单的例子如下：
假定数据银行包括了部分和项目的信息。对于每个部分，它有部分编号，部分名称，部分描述，在手数量，在单数量被记录下来。对于每个项目，项目编号，项目名称，项目描述被记录下来。无论何时，一个项目使用了一个特定的部分，那个部分提交给特定的项目的数量也被记录下来。假定系统要求用户或者是文件的设计者，来声明或者是定义这些树结构中的数据。然后对于如上提到的信息，层次结构中的任何一个可能被采用。（见结构一到五）

结构一项目跟在部分后面
文件片段    域
F       部分   部分编号，
                  部分名称，
                  部分描述，
                 在手数量，
                 在单数量
         项目项目编号，
                  项目名称，
                  项目描述
                  提交数量

结构二部分跟在项目后面
文件片段    域
F       项目项目编号，
                  项目名称，
                  项目描述
        部分   部分编号，
                  部分名称，
                  部分描述，
                 在手数量，
                 在单数量
                  提交数量

结构三部分和项目作为同样重要的主体，提交关系跟在项目后面
文件片段    域
F       部分   部分编号，
                  部分名称，
                  部分描述，
                 在手数量，
                 在单数量
G      项目项目编号，
                  项目名称，
                  项目描述
        部分   部分编号，
                  提交数量

结构四部分和项目作为同样重要的主体，提交关系跟在部分后面
文件片段    域
F       部分   部分编号，
                  部分名称，
                  部分描述，
                 在手数量，
                 在单数量
        项目项目编号，
                 提交数量
G      项目项目编号，
                  项目名称，
                  项目描述

结构五部分和项目以及提交关系作为同样重要的主体
文件片段    域
F       部分   部分编号，
                  部分名称，
                  部分描述，
                 在手数量，
                 在单数量
G      项目项目编号，
                  项目名称，
                  项目描述
H     提交   部分编号
                 项目编号，
                 提交数量

现在，考虑下这个问题，它是在项目名称是阿尔法的项目中为每一个它使用的部分打印出部分编号，部分名称，和部分的提交数量。接下来注意到的是为了处理这个问题，无关于选择哪个可用的面向树的信息系统。如果一个程序P被开发出来，对于这个问题，它假定如上的五种结构之一，也就是P没有测试来确定哪种结构是有效的，那么P至少在三种结构中将失败。更关键的是，如果P在结构五中成功了，它将在其它的结构中都失败；如果P在3或者是4中成功了，它将至少在1，2，5中失败。如果P在1或者是2中成功了，它将至少在3，4，5中失败。在每个例子中，原因是很简单的。对于确定哪个结构是有效的，这个测试缺失了，P的失败是因为做出了试着对一个不存在的文件进行引用（有效的系统视之为一个错误）或者是没有试着做出对包含着需要的信息的文件的引用。对此不确信的读者们可以为这个简单的问题开发样品性的程序。

因此，在常规上看，为开发应用程序而测试被系统允许的所有的树形结构是不具有可实践性的，当在结构上的改变变成了必要的时候，这些程序将失败。

给用户提供了数据的网络模型的系统也会遇到与之相似的问题。在树与网络的例子中，用户和它的程序被要求掌握对数据的用户读取路径的集合。这些路径是否是与在存储的表示中的指针定义的路径密切地相符，是没有关系的。在IDS中相符是极其简单的，在TDMS它恰恰是相反的。因此，无关于存储表示，就是终端的活动与程序变得依赖于用户存取路径的可持续性的存在。

对此一个解决方案是采用策略，这个策略是一旦一个用户存取路径被定义它将不用被丢弃，直到使用这个存取路径的所有的程序都丢弃了这个路径。这样的策略是不现实的，因为在一个数据银行的用户的通信的总体的模型中，存取路径的数量终将变得极其庞大。

1.3 数据的一个关系视图
在这使用的术语关系，在它被接受的数学的语境中。给定集合S1,S2,..
Sn(没有必要区分)，如果R是一个N元组的集合，这个集合中的每个N元组的第一个元素来自于S1，每个N元组的第二个元素来自于S2，等等，那么R是一个在这些集合上的关系。我们将引用Sj作为R的第j个域。正如如上的定义，R被称为有度为N。度为1的关系经常被叫做一元的，度2的是二元的，度3的是三元的，度N的是N元组。

为了开发的缘故，我们将频繁地使用关系的一个数组的表示形式，但是必须记住的是这种特定的表示形式不是被详细论述的关系视图的一个必要的部分。一个数组表示的一个N元组的关系R有如下的属性：
1. 每一行表示关系R的一个N元组。
2. 行的顺序是不重要的。
3. 所有的行是唯一的。
4. 列的顺序是重要的，它对应于R被定义的域的S1，S2,...Sn的顺序。
（见下面的域有序和域无序的关系的解释）
5. 每个列的重要性，被部分地体现在使用相对应的域的名称，来对列
进行标签化。

在图1的例子中，演示了一个度为4的关系，叫做供应，它反映的是
从特定的供应商到特定的项目在指定的数量的部分的船运过程。

供应   （供应商   部分     项目    数量）
                1          2         5        17
                1          3         5        23
                2          3         7         9
                2          7         5         4
                4          1         1         12
图1 一个度为4的关系

一个可能的问题是：如果列被标签为以相应的域的名称，为什么列的顺序是重要的？正如在图2中显示的例子那样，两个列可能有相同的名称
（显示相同的域）但是却拥有不同的与关系对应的含义，被描述的关系
称为组件。它是一个三元组的关系，它的头两个域被叫做“部分”和第三个域叫做“数量”组件（x,y,z）的含义是部分x是部分y的一个直接的组件，（或者子组件），z个部分x 组成了一个部分y. 这是在部分激增的问题中起重要的作用的一个关系。

组件   （部分    部分        数量）
               1         5             9
               2         5             7
               3         5             2
               2         6             12
               3         6             3
               4         7             1
               6         7             1
图2 有两个相同的域的关系

在一些已有的信息系统中，它是一个重要的事实（主要是基于树形结构的文件）对于有两个或者是更多的相同的域的关系，无法提供数据表示。 IMS/360 的现在的版本就是这样的系统的一个例子。

在一个数据银行中的数据的总体可能被视为一个随时间变化的关系的集合。这些关系有各种各样的度。由于时间的流逝，每个N元组的关系可能成为额外的N元组的添加的目标，或者是成为原来的元组的删除的目标，它的原来的存在的N元组的任何一个组件的修改的目标。

在许多的商业性的，政府性的，科学的数据银行中，然而，它的关系中的一些有相当高的度（度为30是很常见的）。用户不应该因为要记住任何的关系的域的顺序而产生负担（例如在“供应”的关系中的顺序是供应商，部分，项目，数量）。据此，我们就假定用户在处理关系时，关系不是域有序的，而是关系有域无序的部分组成。为了实现这个任务，域必须在给定的关系中至少被唯一的表示，而不是使用它的位置。所以
当有两个或者是相同的域时，我们要求在每个情况下域名必须被唯一性的角色而命名，它服务于在一个给定的关系中的那个域标识域扮演的角色。例如，在图2中的关系 “组件”中，第一个域 “部分”可能被命名为角色名称“下级”，第二个命名为“上级”因此用户能够处理关系“组件”和它的域为 “下级的部分”，“上级的部分”和“数量”而没有指定这些域的任何顺序。

如上，它假定的是大部分的用户应该交互的是由一个时序的关系的集合组成的数据的一个关系模型（而不是那些关系）。每个用户不需要知道
关于任何关系的信息，除了它们的名称和它们的域的名称（当需要的时候是角色的名称）甚至这些信息可能被系统以菜单的风格来提供，这依赖于用户的请求（这是安全和隐私限制的主题了）

这有很多的可选的方式来创建数据银行的关系模型。为了讨论一个更优的方式（或者是规范的形式）我们必须首先介绍一些附加的概念（活跃域，主键，外键，非简单域）并且以在信息系统中的编程中使用的术语建立一些链接。在这个文章的余下的部分，我们将不再区别数学中的关系与实际中的关系，除非它们表现得特别明显的区别。
考虑一个数据银行的例子，它包括了如下的关系，部分，项目，供应商。一个关系叫做“部分”它定义了如下的域：
1。部分编号
2 部分名称
3 部分颜色
4 部分重量
5 在手的数量
6 在单的数量
并且也可能有其它的域。这些域中的每一个都有一个有效的值的范围。它们中的一些或者是所有的可能在数据银行的每个时刻都有表示。然而可能的是，在某些时候，所有的部分的颜色都是当时的，它不像所有的可能的部分的重量，部分的名称，和部分的编号。我们将称呼在某个时候表示的值的集合为那个时候的活跃域。

现在，一个给定的关系的一个域（或者是域的组合）是有唯一性的值来标识为那个关系的一个N元组。这样的域（或者是组合）被叫做主键。在上面的例子中，部分编号可能是主键，而部分颜色不是主键。如果它是一个简单的域（非组合）或者是这样的组合，它的每个组成它的简单域在唯一性地标识每一个元素时，没有哪一个是不必要的，这样的话，一个主键是非冗余性的。一个关系可能拥有多个非冗余性的主键。如果部分的名称总是有唯一性的名称，在上述的例子中，这就是多主键的例子了。无论何时，当一个关系有两个或者是多个主键时，它们中的任何一个可以被选择，作为关系的主键。

一个普通的需求是一个关系中的元素交叉引用了相同的关系中的其它元素或者是一个不同的关系中的元素。键提供了一个用户导向的方法，这方法表达了这种交叉引用，但它不是唯一可用的方法。我们把一个关系中的一个域（或者是域的组合）叫做外键。是在它满足了如下的条件时。它不是关系R的主键，它的元素的值是一些关系S中的主键的值（S和R的同一个的可能性没有被排除）。在图1中的“供应”的关系中，供应商，部分，项目的组合是主键，这三个域中每个分别是一个外键。

在前面的工作中，有一个强的趋势是把一个数据银行中的数据视为两个部分，一个部分是实体的描述（例如供应商的描述）和组成关系的其它部分。这关系是各种实体和实体的类型（例如“供应”关系）当一个关系可能有任何关系的外键时，这种区别是很难维护的。在用户的关系模型中做这种区别是没有优势的（有可能的优势是当一个关系的概念被应用到关系的用户集合中的机器表示中。）

所以我们已经讨论了关系的例子，当它被定义为简单域，即域的元素是原子性的（不可分解的）值。在关系的框架中能讨论非原子性的值。因此一些域可能有关系作为元素。这些关系是反过来被定义在非简单的域上的，等等。例如 “员工”这个关系上的域之一可能被定义为工资的历史。工资历史的元素之一是一个二元的关系，这个关系是定义在域 “日期”和域 “工资”。域“工资历史”是所有的这些二元关系的集合。在任何一个时刻，由于有许多的员工，在数据银行中的关系“工资历史”中都有许多的实例。相反的是，在员工的关系中仅有一个实例。

术语“属性”和可重复的群在现有的数据库术语中是与简单域和非简单域是对应相似的。在现有的术语的结论中的很多归结于在类型与实例的区分的失败，还有数据这方面的用户模型的组件与另一方面的它们的机器表示部分之间的区别的失败（我们再以“记录”作为一个例子）