翻译 大型共享数据库的数据关系模型(精选.)

  • 格式:doc
  • 大小:208.00 KB
  • 文档页数:17

下载文档原格式

  / 30
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

大型共享数据库的数据关系模型

E.F.Codd

IBM 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)。