|
|
51CTO旗下网站
|
|
移动端

《视图更新与关系数据库理论》本书详细介绍了数据库架构的设计和实现,同时讨论了视图更新及关系数据库理论。本节为序。

作者:田远帆 译来源:人民邮电出版社|2018-01-25 17:04

在关系型数据库及其实际应用领域中,一直有两个特别棘手和富有争议的问题,而业界并没有得出一个大家都能满意的解决办法,这两个问题是:信息丢失问题和视图更新问题。对第1个问题,Chris Date在过去30年左右的时间里已经撰写了大量著作,现在他开始着手应对第2个问题。

当然他在之前并非没有涉及视图更新这个问题。在他著名的著作,被作为教科书广泛使用的《An Introduction to Database Systems》中就有对该问题的讨论。在1975年第1版发行的时候,书中就有少量篇幅涉及这个问题;到第8版时(2004年),书中已经有多达16页左右的篇幅来进行讨论。他第一次用整个章节讨论这个问题是在1986年开始撰写系列丛书《Relational Database Writings》的时候。到了1995年,在该系列第4本书中,他和David McGoveran带给了我们两个章节的内容来展示对这个问题思考的变迁,这些内容更多地源自McGoveran的研究。这个思考后来在《Databases, Types, and the Relational Model: The Third Manifesto》(2007)的附录中进化,在《Database Explorations》(2010)的章节中成长,最终到了今天的地位。

最初由E. F. Codd在1969年提出的基础理念,至今一直都没有变化。想象现在给定一个数据库,根据定义是由(a)可变关系或者“关系变量”[1]组成的集合,同时由(b)一套完整性约束管理着这些关系变量的可用值。这些给定的关系变量都是“基础”变量。总体来说,被选出的设计是在许多个设计中可以被选出来代表完全相同信息的那一个。从被选出的设计中我们可以根据基础关系变量的关系表达式,通过定义虚拟关系变量,从而得到一个备选方案。由于各种各样的原因,这样一个备选设计,实际上是一个备选的数据库视图,可能相对基础设计来说更适合某些特定用户。更重要的是,这个备选设计可能实际上并不包含底层的或者“真正的”数据库。有些用户对这些其实也不感兴趣,或者根本没有权限看到。除此之外,如果必须针对基础设计做出一些变化,代表原始设计的虚拟关系变量可以在新设计上被重新定义,这样一来已经存在的用户视图就无需改变,那些可能发生的令人讨厌的突变就可以避免。这就是著名的终极目标“逻辑数据独立”背后的基础理念。

如果用户把虚拟变量视为他们的数据库,当实施与虚拟关系变量冲突的数据库更新时,棘手的问题就出现了。数据库管理系统到底是如何判定那些对真正的数据库实施真正的更新会对虚拟关系变量产生特定的改变的?如果这里有数种方式可以实现需要的效果,那么到底该选用哪种方式呢?举个简单的例子,假设一个用户使用常见的“供应商与零部件”数据库(第1章有详细介绍),他看到一个虚拟关系变量或者视图命名为“PS”,其中只显示位于巴黎的供应商。毋庸置疑,PS的定义表达式是“S WHERE CITY = 'Paris'”。现在,我们假设这个用户让数据库管理系统从视图PS中删除数组S2。那么数据库管理系统是否应当这样理解用户的意图:供应商S2不存在了,需要从基础关系变量S中删除相应的底层数组?还是说应当因为用户表述不清而拒绝客户的删除指令,因为将供应商S2的CITY值换成巴黎以外的地方也会达成相同的效果?或者在另一种情况下,假设用户知道供应商S2已经搬迁到伦敦,因此尝试在视图PS中对S2进行“更新数组”的操作来达到从视图PS中删除数组S2的效果,那么数据库管理系统是否应当接受这个更新操作呢?现在我们进一步假设视图PS没有STATUS(状态)属性。那么数据库管理系统应当如何回应该用户对视图尝试插入数组的操作,而用户要求这些数组必须要删除STATUS值?

针对以上和更多的此类问题,Date都试图在他详细的、全面的、细心的、有条理的分析中为我们做出解答。他计划在最开始的3个章节中对这些问题发起进攻。他清楚地定义了“2个数据库被设计为在表达相同信息的时候是等价的”是什么意思,然后在接下来的10个章节,他将对他所使用的方法进行详细讲述。这个方法需要轮流检验每一个关系代数中的操作。例如,那个“只包含巴黎供应商”的视图PS被他称为约束视图,比如,定义一个虚拟关系变量只使用约束操作。同样地,现在定义一个不包含PS中STATUS属性的视图使用投影。既然这个视图是一个约束的投影,我们可以来推断它的更新效果。首先根据Date的更新规则通过投影来决定对底层约束的效果,然后根据更新规则通过约束来决定对底层基础关系变量S的效果。

对由一些关系操作定义的视图应用这些规则的时候会产生一个非常有趣,甚至可以说是很有争议性的问题,这个问题Date在第14章会做阐述,那就是如果两个表达式在语法上不同,但逻辑上等价。例如,数学表达式x(y+z) 和xy+xz在语法上不同,但逻辑上是等价的。那么定义于它们之上的视图在执行更新操作的时候运行行为(如过程、动作或效果等)是否一定要完全相同?

现在,Date的一些观点在我前面提到的2007年和2010年的出版物上出现的时候,被证明是具有争议性的。例如,当我们向R1和R2的合并视图插入1个数组时,这个数组是否应该同时出现在R1和R2之内?如果我们从R1和R2的交集视图中删除一个数组时,是否会导致这个数组从R1和R2中同时消失呢?作为针对那些具体观点表达不同意见的一员,在这里我要强调,在我和Date长时间的合作过程中,我们之间唯一非常严重的技术分歧已经出现。这些争议点在本书中也有展现,并且Date已经针对这些问题加强了基本原理的解释,不过这可能仍然无法让所有人都信服他的观点。而我发现,在他的最后一章“歧义问题再回顾”中出现了希望之光,就好像是隧道尽头的那一盏明灯。在其中他描述了一个想法的大概轮廓,由David McGoveran提出的一种与以往我们更新关系型数据库所采用的方式完全不同的方式,它可以很有效地替代,或者至少是拓展,我们所熟知的“插入”“删除”和“更新”这些早在关系型时代之前就与我们紧密相连的操作。而这种不同寻常的方式所带来的好处是,我之前提到的会产生争议的问题根本不会出现了。

Date告诉我,他并没有期待,甚至没有想过让本书成为他关于视图更新故事的结尾,但他希望本书能够给现存的争论提供一个坚实的理论基础,以使得整件事情可以向前推进。我想这正是他在本书中所提供的,我在这里也希望本书对你有相同的效果。

Hugh Darwen

于英格兰Shrewley区

2013年


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

C#和.NET核心技术

本书重点讲解如何用实用的代码来解决具体的实际问题。本书的内容覆盖面很广,从新的C#范型到Web服务,从反射到安全等都有涉及。系统地介绍...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊