2022年翻译大型共享数据库的数据关系模型 .pdf
《2022年翻译大型共享数据库的数据关系模型 .pdf》由会员分享,可在线阅读,更多相关《2022年翻译大型共享数据库的数据关系模型 .pdf(17页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、大型共享数据库的数据关系模型E.F.Cod d IBM Research Laboratory,SanJose,California 未来的数据库使用者一定是和数据在机器中的存储(即数据库的内部模式)相隔离的。而通过提示服务来提供信息是一个不太令人满意的解决方法。当数据的内部模式表示发生改变,甚至数据内部表示的多个方面发生改变时,终端用户和大多数应用程序的活动都不会受到影响。 因此, 查询、 更新和报告存储信息类型的自然增长和变动都需要在数据表示中表现出来。现存的不可推断的、格式化的数据系统给用户提供了树结构的文件或者更一般的网格模式的数据。本文在第一部分讨论这些模式的不足之处。并且会介绍一种
2、基于n 元组关系的模式,一种数据库关系的正式形式和通用数据子句的概念。第二部分将讨论一些关系的操作(不是逻辑层面的) ,并且把这些操作应用于用户模式上解决冗余和一致性问题。1关系模式和一般模式1.1 简介这篇文章是关于系统的基本关系原理的应用,这个原理提供了共享大型格式化数据库的方法。除了Childs1 的文章有介绍外,用于数据库系统的关系的主要应用还表现在演绎推理型的问-答系统中。 Levein 和 Maron2 提供了大量关于这个领域的参考资料。相比之下,这里要解决的问题是一些数据独立性的问题应用程序和终端活动之于数据类型增长和数据表示变动的独立性,而数据一致性问题即使在非演绎推理型系统中
3、也是很棘手的。在目前流行的非推论性系统中,第一部分要介绍的数据的关系视图(或叫做模式)在一些方面似乎优于图模式和网格模式3,4 。这种模式提供了一种根据数据的自然结构来描述描述数据的方式 也就是说,不用为了数据的机器表示而添加其他的将结构。因此,这种模式为高水准的数据语言提供了基础,而这种数据语言机制一方面可以达到最大化程序之间的独立性,另一方面也可以最大化数据的机器表示和组织之间的独立性。关系模式更高一级的优势在于它构成了关系处理可导性、冗余性和一致性的坚固基础 这些将在第二部分讨论。另一方面,网络模型产生了一些混淆,尤其是把连接的源误作为关系的源(见第二部分“ 连接陷阱 ” )最后,关系视
4、图允许对目前格式化数据系统的范围和逻辑限制的更清晰的估算,并且有在单独的系统内竞争数据表示方式的优点(从逻辑的观点) 。更清楚的这个观点的示例会在本文中的不同部分中被阐释。但是支持关系模式的系统实现不会讨论。1.2 目前系统的数据相关性最近发展的信息系统中数据描述表的提供是向数据独立性目标5,6,7 靠近的重要提高。这些表可以使改变数据库中数据表示的某些特征变得更容易些。但是,许多数据表示特征可以在不逻辑地削弱一些应用程序的情况下被改变的功能仍受到相当的限制。更进一步,与用户交互的数据模式仍然有一些散乱的代表性特征,特别名师资料总结 - - -精品资料欢迎下载 - - - - - - - -
5、- - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页,共 17 页 - - - - - - - - - 是关于数据收集的描述(如个人名目) 。三个仍然需要提高的数据独立性的主要类型是:排序依赖,索引依赖和存取路径的依赖。在一些系统中这些依赖之间并不是明确分隔的。1.2.1 顺序依赖。数据库中的数据元素可以有很多种存储方式,一些是不考虑顺序的,一些是允许一个元素只参与一个排序,而另外一些允许每个元素参与多个排序。现在让我们来看看要求或允许数据元素存储在至少一个总排序的现存系统,而这种总体排序是与硬件决定的排序地址密切相关的。这种系统通常允许应用程序自己假定
6、文件记录的表示顺序与其在磁盘上的存储顺序是相同的(或者说是存储排序的子目)。这些运用文件存储顺序有利条件的应用程序,如果由于某些原因而变得需要用一个新排序替换这种顺序时,很可能不能正确运行。以指针方式实现的存储排序也有相似的问题。我们没有必要挑选出任何一个系统作为例子,因为现在上市的所有著名的信息系统在清楚区别表示顺序和存储顺序两方面都是失败的。重要的实现问题必须得到解决来提供这种独立性。1.2.2 索引依赖。 格式化数据的上下文联系中,索引通常被看成数据表示的一个纯粹的效能导向组件。它倾向于提高对查询和更新的响应,同时减慢了对插入和删除的响应。从信息的观点来看,索引是数据表示的冗余构成成分。
7、如果一个系统王全用索引, 并且如果它在变化活动形式的数据库环境中能够表现的很好,那么不时地产生和销毁索引的能力可能是必须的。那么问题产生了:应用程序和终端活动在索引项来去的时候仍然能够不受影响吗?目前格式化数据系统采用很不相同的方法来进行索引。TDMS7 无条件地提供了所有属性上的索引。IMS5 目前发布的版本为用户提供了为每一文件选择的权利:是完全没有索引(层次序列的组织)和只有主键索引(层次化索引序列组织) 之间的选择。 没有一种会使用户的应用逻辑依赖于无条件提供的索引的存在。但是,IDS8 允许文件设计者选择用于索引的属性和指定用于与索引通过外加链的方式组合成文件结构的属性。运用索引链性
8、能的优势的应用程序必须通过名字来引用这些链。如果这些链后来被删除,那么这些程序就无法正确运行。1.2.3 存取路径依赖。 许多现存格式化数据系统为用户提供了树结构的文件或者更一般的数据网络模式。为和这类系统共同工作而发展的应用程序,在树或网格的结构改变时,往往会在逻辑层受到削弱。一个简单的例子如下。设想数据库包含关于部件和工程的信息。对于每一个部件,其部件号码、部件名字、部件描述、在手的数量和订单上的数量的信息都被记录。对于每一个工程,其工程编号、工程名字和工程描述信息被记录。无论什么时候,一个工程要用特定部件时,用于这个工程的那种部件的数量也会被记录。假如系统要求用户或者文件创作者根据树结构
9、声明或者定义数据。那么,任一层次结构都可以用到如上提到的信息上(见结构1 5) 。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页,共 17 页 - - - - - - - - - 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页,共 17 页 - - - - - - - - - 现在考虑打印用于名为“alpha “的工程每个部件的编号、部件名和数目。 不考虑可
10、用于面向树的信息系统可以用于解决这个问题,我们可以得到以下的发现。如果程序P 是开发用于解决这个问题(假设结构是上面五种结构中的一种) ,也就是说P 不会检测哪一种结构对他来说有效,然而这样的结果是P至少在其中三个结构上是失败的。更具体地, 如果 P 对结构 5 行之有效, 那么在其他结构上就会失败;如果 P 对结构 3 或 4 行之有效, 那么它至少会在结构 1,2,5 上是失败的;如果P 对结构 1 或 2 行之有效,那么它至少会在结构 3,4,5 上是是小的。对于每一种情况的原因都很简单。在没有经过检测来决定哪种结构是有效的情况下,P 会失败是因为它试图引用一个不存在的文件(现可用的系统
11、把这种情况视为error )或者是它没有引用包含它必需信息的文件。有疑问的读者应该找一些样例程序来理解这个简单的问题。由于在一般情况下, 开发可以检测系统允许的所有树结构的应用程序是不实际的,而且这种程序在结构需要改变时也会失败。为用户提供网格数据模式的系统也会遇到相似的问题。在树和网格两种情形下,用户(或者是用户的程序)都被要求采用用户数据存取路径的集合。这些路径是否与存储表示的指针定义的路径有较近通信是没有影响的,而在IDS 中这种通信时极其简单的,但在TDMS 中就正好相反了。不考虑存储表示来看这种问题,结果就是, 终端活动和程序变得依赖于用户存取路径的连续存在性。对于这个问题的一个解决
12、方案就是采用如下策略:一旦用户存取路径被定义了,那么除非所有应用这个路径的所有程序都废弃了(finish 了) ,否则这个路径就不会过时。 由于在团体总体模式的数据库用户的存取路径的数量最终可能变得过大,因此这种策略是不实际的。1.3 数据的关系视图关系这个词在这里使用的是其被广泛认可的数学意义。给定集合S1,S2,Sn(这些集合没有必要一定是不同的),如果R 是一个满足如下条件的n 元组集合:其每个元素的第一个元素来自S1,第二个元素来自集合S2,以此类推,那么R 就是这n个集合( S1,S2,Sn)上的一个关系。我们用Sj 来表示 R 的第 j 个域。正如上面所定义, R 被称作是 n 级
13、的。 1 级的关系通常叫做一元关系,2 级的被叫做二元关系,3 级的被叫做三元关系,而n 级的叫 n 元关系。(更简单地说,R 是 S1,S2, ,Sn这n 个集合的笛卡尔乘积的一个子集)说明一下,我们将频繁地使用关系的数组表示,但是必须清楚的是这个特定表示并不是用于解释关系视图必须的部分。用于表示n 元关 R 的数组有如下特征:名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页,共 17 页 - - - - - - - - - (1)每一行代表R 的一个 n 元组(2)行的排列
14、顺序是无关紧要的(3)所有行都是不相同的(4)列的顺序是有意义的 列应该符合R 定义时的域的顺序S1,s2, ,Sn(但是注意,排序的域和无序的域下标之间的关系)(5)每个列的意义部分是由命名相应域来传达的图 1 中的例子展示了一个叫做supply 4 级的关系, 这个关系显示的是特定工程的特定供应者的特定数量的零件发货过程。图 1 有人可能会问: 如果列由相应域的名字来标识,那么为什么列的顺序会有影响呢?正如图2 中例子显示的一样,两列可以有相同的头(表示同样的域),但是对于这个关系他们有不同的含义。这里描述的关系叫做component 。它是一个三元关系,其中前两个域叫做part 而第三个
15、域叫做quantity 。Component (x,y,z)的意思就是部件x 部件 y 的直接构成成分(或者子部件),而需要 z 个的 x 部件来组成一个的y 部件。这个关系在零件扩大问题中有重要作用。图 2 一个引人注目事实是,一些现存的信息系统(主要是基于树结构文件组织)不能够为有两个或两个以上的相同域的关系提供有效地数据表示。IMS/3605的目前版本就是这种系统的一个实例。一个数据库中的总体数据可以看做一个随着时间变化的关系的集合。这些种类的关系有各种各样的级(或度)。随着时间的前进,每个n 元关系都可能经历插入另外的 n 元组,删除现存的n 元组和改变现存任意n 元组的组成部分的操作
16、。但是,在很多商业、政府和科学数据库中,一些关系的度(或作级别)是相当高的(30 级的关系也是很常见的)。 用户通常不能记住任何关系的所有域的顺序(例如,关系 supply 中定序的提供者、零件、工程和数量)。因此,我们提出用户不必处理域排序的关系,而处理与其非排序域的有同样效果的关系的方法。为了达到这个目的, 关系中的域必须是在不采用位置时唯一可确认的,至少在某个给定的关系中是这样的。 因此, 在有两个或更多相同域的地方,我们要求对每一种情况下域名都是合格的不同的角色名(role name) ,这些角色名用于识别给定的关系中的域所扮演的角色。例如,在图2 的 component 关系中,第一
17、个域part 可以用合格角色名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页,共 17 页 - - - - - - - - - 名 sub 指示,而第二个用super ,以便用户能够处理component关系和它的域sub.partsuper.part,quantity 而不用考虑这些域之间的任何排序。总之, 提出多数用户应该与由随时间变化的联系集合(而不是关系) 组成的数据的关系模式交互。 每个用户不必知道除了关系的名字和其相应的域的名字外的其它更多信息(只要有需要就可以采用
18、角色资格)。甚至信息可以是系统(具有安全和隐私约束)根据用户的请求以菜单形式提供的。数据库关系模型的建立通常还有其他很多可供选择的方法。为了讨论更好的方式(或标准形式) ,我们必须引入另外几个概念(活动域、主码、外码、非单一域)并建立一些与目前在信息系统编程中使用的术语的链接。在本文后面的部分,我们将不再烦恼地去区别关系(relation )和联系( relationship ) ,而在需要显示他们不同之处的地方我们会显示地指出。下面考虑这样一个数据库实例,该数据库包含关于部件,工程和供应者的一系列关系。一个叫part 的关系被定义在以下的域上:(1)部件编号( part number)(2)
19、部件名称( part name )(3)部件颜色( part col or)(4)部件重量( part weight )(5)在手的数量( quantity on hand )(6)预订的数量( quantity on ord er)可能还有其他的域。事实上, 每个这样的域都是一池数值,这些数值中的一些或全部可以在任一瞬时在数据库中表示出来。可以想象, 在某些瞬间, 所有部件颜色都被显示出来, 但是难以做到的是把所有可能存在的部件的重量、部件名字和部件编号都显示出来。 我们称在某个时刻表现出来的值的集合为在那个时刻的活动域(active domain ) 。通常, 一个给定关系的一个域(或者域
20、的组合)有一组唯一识别该关系的每一元素( n 元组)的值。这样的一个域(或组合)被叫做主码(primary key) 。在上面的例子中, 部件号可能是一个主码,而部件颜色可能就不是了。主码是非冗余的,如果他满足它是一个简单域(非组合的) 或者一个组合, 而对于组合的情况,在唯一识别每一元素时参与到这个组合中的简单域没有一个是多余的(也就是组合中的所有的简单域共同构成一个唯一识别关系元素的码)。一个关系可以有多个非冗余的主码。如果上面所说的部件的名字都互不相同,那么就成了这种情况的一个实例。无论什么时候, 只要一个关系有两个或者更多非冗的主码,它们中的任意一个都可以选作这个关系的主码。一个普遍的
21、要求就是, 关系当中的元素交叉引用同一关系的其他元素或者引用一个不同关系的元素。码提供了一种用于表示这种交叉引用的面向用户的方式(但不是唯一的方式) 。如果一个域(或者域组合)不是关系R 的主码,但是它的元素是某个关系S 的主码值(排除S和 R 是同一关系的可能) ,那么我们就把关系R 的这个域(或者域组合)叫做外码。在图1supply关系中, supplier 、part 、project是主码,而这三个域中每一个都被单独看作是一个外码。在前面的工作中已经显现出一个很强的趋势,即把一个数据库中的数据看成由两个部分组成,一个部分由实体描述组成(如supplier的描述),而另一个部分由不同实体
22、间或者实体类型间的关系组成(如 supply 关系)。当一个关系有任何其他关系的外码时, 要维持这种区别是困难的。在用户的关系模式中,做出这样的区别似乎是没有益处的(但是, 当把关系概念用于用户联系集的机器表示时,这种区分名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页,共 17 页 - - - - - - - - - 可能有些益处) 。到目前为止, 我们已经讨论了一系列定义在简单域上的关系的例子,而那些简单域的元素是原子的(非组合的)值。非原子值会在关系框架中讨论。因此,一些
23、域可以把关系当做元素。相应地, 这些关系可以被定义在非简单域等等。例如, 关系 empl oyee 定义的其中一个域可以是salary history (薪水历史) 。Salary history域中的一个元素是一个定义在date 域和 salary 域上的二元关系。Salary history 域就是这种二元关系的一个集合。在数据库中任意瞬间都会有与empl oyee(员工)数量相同的salary history关系实例。相比之下,employee 关系就只有一个实例。在表示数据库的术语中属性和重复组分别在简单域和非简单域中是大致相似的。现在术语中的多混淆之处是由于没能把类型和实例(如在“r
24、ecord ”中)区别开和把数据的用户模式的组成和它们相应的机器表示区别开(再次以“record ”为例)。1.4 标准形式一种所有域都是简单域的关系能够用如上讨论过的二维的齐次列数组来表示其存储形式。一些更为复杂的数据结构对一个有一个或多个非简单域的关系是必要的。由于这个原因(其他的将在下面举例),消除非简单域的潜力似乎值得投资。事实上,有一种简单的消除过程,而我们把这个过程叫做标准化。例如, 考虑图 3(a)显示的关系集合。Job history 和 children 是 empl oyee 关系的非简单域。 Salary history是 job history的一个非简单域。图 3(a
25、)中的树展示了各个非简单域之间相互关系。图 3( a)图 3(b)标准化按如下程序进行。从关系的树顶端开始,记住它的主码,并且通过插入主码域或者域组合来扩展每个直属的下层关系。每个扩展关系的主码由从父关系(即上一层的关系)拷贝下来主码在进行扩大前的主码构成。现在,从父关系中化掉所有非简单域,删除树的顶节点,并且在留下的子树上重复同样的操作程序。图 3(a)中标准化关系集合的结果就是图3(b)中的集合。每个关系的主码都用斜体表示以显示这些码值是如何通过标准化来扩展的。如果要使得如上所述的标准化是可用的,那么关系集合的非标准化必须满足如下条名师资料总结 - - -精品资料欢迎下载 - - - -
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 2022年翻译大型共享数据库的数据关系模型 2022 翻译 大型 共享 数据库 数据 关系 模型
限制150内